2024-05-23 Meeting notes

Updates

Feanil Patel

• Switching edx-platform unit tests to standard ubuntu runners

• CI will fail if a Python package is added that lives in the edx org

  • Encourage EXTRA_REQUIREMENTS instead of direct deps

  • Not just edx. It’ll be a denylist

    • edx

    • mit-odl

    • open-craft

    • et al

  • Third-parties (Django) are fine

  • Temp allowlist for current ones

High-level arch brainstorming/tracking - what’s a good space?

Kyle McCormick

https://docs.google.com/document/d/1s-Aqbq8ohA-YG9jhrV3VCQyAUXDQgE8nq4DH7Ntr79E/edit

Where should stuff like this ^ live?

edx-platform GitHub issues

Board?

• Feanil: maybe not

• Robert: how do we prioritize?

Docs for things we’ve already decided - e.g. no new legacy frontends

Put it on the platform-roadmap? when it’s ready

Maintenance board?

Apply labels:

• code-health + epic

• architecture + epic ?

Kyle will turn the google doc into issues and figure out how to organize them

edx-platform app-level docs

Robert Raposa

• https://docs.openedx.org/projects/edx-platform/en/latest/references/docs/index.html - RST docs from within edx-platform repos.

Ideas:

• Add app-level READMEs

• Add top-level index page to make discovery easier.

• Eventually update OEP-19 with best practices for exposing these for a repo.

Redwood bug triage for edx-platform

Kyle McCormick

We expect that

• bugs will be found in release testing

• BTR will triage them

  • if they belong to an active dev team (eg tagging), they work on the fix

  • but if they are unexpected regressions, then BTR will triage the severity..

    • if it’s a release blocker, then BTR will find the maintiner

    • if it’s edx-platform, then we are the maintainer, so we’ll need to figure out how to find the right person/team to do the fix

    • Let’s cross that bridge when it happens. No action needed now.

[switch to full maintenance WG mode]

3m

Sarina

Any appetite to update guidelines around pinning constraints? See idea: https://github.com/openedx/open-edx-proposals/issues/332

• Please provide your input on this issue.

Dependabot PRs

Robert Raposa (unless Jillian Vogel joins)

From Jillian Vogel:

I've started maintaining a couple of openedx repos, and am working through the dependabot PRs. 

Does anyone have any advice for me?  I'm curious how people manage the continual stream.

• For minor version updates, is it OK to trust the CI, or are people doing manual testing too?

  • No, trust your CI but if you don’t trust your CI, invest in it.

• When to bump the package version?

  • Updates should run at-least on a weekly basis. One recommendation is that you make all the schedules for the repos you maintain, the same.

  • Dropping support for major upstream deps(django, drf, react) should be done in coordination with the rest of the edx-platform project.

  • Updates to test requirements don’t warrant a version bump or changelog entry, since they are not exposed by setup.py

• Docs that could be updated :

  • https://docs.openedx.org/en/latest/developers/how-tos/enable-javascript-upgrade-automation.html

  • https://docs.openedx.org/en/latest/developers/how-tos/enable-python-upgrade-automation.html

Un maintained repos

Chintan Joshi

https://docs.google.com/spreadsheets/d/1tQZsLNhcsH3Kh35nHWCWZo-5wvZADFTobVcpN-13sW8/edit?usp=sharing - Chintan is gonna try to do some of the initial maintenance on a bunch of these.