Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

⏪ Previous TODOs

DescriptionAssigneeTask appears on
  • Next time: Discuss access for teams that maintain many repos across the org.
 2024-09-19 Meeting notes
  • Feanil Patel ticket enabling cron CI of master every week so we know when external changes might have broken some repos that are usually not getting updates.
Feanil Patel2024-09-12 Meeting notes
2024-09-05 Meeting notes
  • Kyle McCormick Next time: Py 3.13 or Py 3.12 for next upgrade? Take a look at the changelog.
Kyle McCormick2024-09-05 Meeting notes
  • Jeremy Ristau ensure DEPR tickets are created for any frontend that can be deleted as a result of the new course-authoring MFE.
Jeremy Ristau2024-05-30 Meeting notes

\uD83D\uDDE3 Discussion topicse

Item

Presenter

Notes

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

[time permitting] edx-platform sub-maintainers

Kyle McCormick


✅ Action items

  •  

⤴ Decisions

  • When breaking infrastructure or interfaces that the community relies on, we should have an agreed upon expand phase (maybe 6 months as default similar to releases with exceptions where it makes sense) where both the old and new versions work.
  • No labels