Topics
Brainstorm on next round of Blended Development ideas
Blended Projects ⭐ 🌴
(italicized blue = probably self-contained effort; red = will probably need more hand-holding with edX engineers; bold green = on blended board)
Misc
Adding more tools to https://support-tools.edx.org (MFE support tools), DEPR https://courses.edx.org/support (old support tools) 🌋
Working through the DEPR backlog (may be red)
Code Health ⭐⭐⭐⭐
Implement list of desired repo health checks (and possibly suggest new ones) 🌴 🌴
Fix remaining issues with using Black (or similar), start using it to standardize code formatting 🌋 🌴
edx-platform code health
Find and fix import direction issues in edx-platform (make it more logical, easier to move things out); e.g., fix it so things under common don’t import from lms packages, etc. 🌋
maybe as part of or as a result of this: restructuring the platform to be more comprehensible/approachable
Not a new idea, but giving a +1 for the pylint cleanup and other edx-platform cleanup -Kyle 🌋🌋🌋 🌋 🌴
Developer Experiences
Removing paver 🌋 🌋
Ditching karma/jasmine in favor of jest - many tests could probably be re-written fairly easily
(karma/jasmine are much slower and more finicky)
Fixing legacy frontend tooling
Anything more specific here?
e.g., running JS Tests locally - running single tests 🌋
Testing ⭐
Prototype consumer-based contract tests (Pact) (may be red)
If we decide they’re worth keeping – Improving our end-to-end tests
or implementing a new suite on better technology 🌋
Migrate our remaining browser automation tests (a11y, e2e, etc.) from bok-choy/Selenium to cypress or playwright
Frontend Maintenance ⭐⭐
DEPR-100 - deprecation and removal of old frontend libraries: frontend-auth, frontend-i18n, frontend-analytics, frontend-logging, frontend-base
Some MFEs may be private and can’t be updated via outsourcing.
Transitioning our ES6 repos from eslint-config-edx to @edx/eslint-config.
Upgrading our ES5 code to use all the ES6 language features that are now supported by our supported browsers, hopefully to aid the removal of our ES5 eslint-config-edx configuration.
How to do versioning for devstack?
flagging last good images/commits
consider Open edX community releases also (Koa, Lilac, etc)
Jinder reviewed past issues in #devstack-questions
Observation: various issues with “certain versions” of devstack - that could be fixed by just going to a known working version
Q: how is versioning of devstack different from versioning of services?
Various versions:
Images
Devstack code
Repo code
Built assets
Data models
Note: we already have Git versions and image versions, but we don’t have an “easy” way to go in-between versions.
Q: what other ecosystem in the open source community may have similar problems that we can look at?
OpenStack? Has its own devstack, and lots of services
Q: could using pip-sync be better than pip-install?
Note: docker has a layered image cache that allows selective pulling of images
If we started the base image with a particular version (like the Open edX named release), then only add incremental changes.
Ideas:
Guidelines for troubleshooting
A named/stable release of devstack, which includes a collection of versions that are known to work well together.
“Pin” dependencies
Down-voting “bad versions” through a bot that devstack references
Just use Docker in the correct way
Image layering with more stable base images
React - Discussions Forum - editor input - draft JS
DJoy: draft JS is fine, need more info to understand tradeoffs.
Backlog of Questions/Discussions
This section lists a backlog of previous proposed topics that haven’t yet been discussed.
Shopping cart deprecation with Diana
lessons learned, knowledge sharing on dead code, etc.