Page Comparison

Tracking Work in Progress Specific to edx-platform

Feanil Patel

• DEPR

• https://github.com/edx/edx-arch-experiments/issues/612

• What we have

  • full maintenance board

    • not clear what’s in flight, who’s leading

    • idea: without a clear leader, tickets should remain way on the left

  • depr board

• Problem

  • No clear place to track edx-platform specific maintenance work

  • We need prioritization, esp for people who are closely following master

    • Also: the general (not edx-platform) version of this problem

      • do we need an edx-platform-specific solution? or is edx-platfom big enough that it becomes the general problem?

  • We have 3 phase to the maintenance work that we could be thinking about.

    1. DEPR and Upgrade Planning Ticket to declare the work should be done.

    2. Ticket/PR to actually do the work.

    3. Provider/Operator need to react to those breaking changes.

       • master vs named release

  • How we did it for Py38->311

    1. Big upgrade ticket for Py38->311

    2. Big ticket had task list for packages and services, nested task lists

       • Some sub-tickets still open since they weren’t prioritized

    3. Reacting

       1. 2u → No tickets on the maintenance board

       2. Tutor → tracked this with tickets separately

  • Wait, maybe it’s 4 steps:

    1. Plan (announce Py38->311 , make an epic)

    2. Expand (add Py11 support)

    3. React (operators switch to Py11)

    4. Contract (remove Py38 support)

  • Some things benefit from expand-contract, others don’t so much

  • Perhaps we only care about this for changes that impact infrastructure or interfaces.

edx-platform Improvements / resiliency

Robert Raposa

• What kind of dependencies are there on other services? Can we make the LMS more resilient to other services going down?

  • Discovery/Programs Cache

• Ensure rate limiting more globally (defaults, etc.)?

[time permitting] edx-platform sub-maintainers

Kyle McCormick