Topics

Brainstorm on next round of Blended Development ideas

• Ref: Arch Tea Time: 2020-03-19 (Blended Dev Ideas)

• Ref: https://openedx.atlassian.net/wiki/spaces/AT/pages/1385529780

• Ref: Needed Architecture Investments

• Ref: Blended Development Runbook and Best Practices

Proposal to move forward with (based on ideation below):

1. Code health

   1. Implement list of desired repo health checks (and possibly suggest new ones)

   2. For the pylint cleanup

   3. edx-platform cleanup (TBD - need to refine this)

2. Frontend maintenance & discovery

Voting Legend:

• was used first, for each participant’s favorite top-level, bolded category

• was used next - each participant got 3 of these votes, and put them on specific items they wanted to see happen

• was then used only inside Code Health to pick your one, top favorite item.
  (italicized blue = probably self-contained effort; red = will probably need more hand-holding with edX engineers; bold green = on blended board)

Ideas and Votes:

• 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)

    • What environment is running in prod? (Python and Ubuntu versions, etc.)

    • Does this service still use ansible for deployment?

    • Do the Ansible and Dockerfile match in important respects?

    • Is there any non-ASCII in setup.cfg?

  • 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

      • Pain points:

        • Escaped bugs

        • Can’t leverage pylint feedback in edx-platform IDE

      • Removing paver

• 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

  • Ditching karma/jasmine in favor of jest - many tests could probably be re-written fairly easily

    • (karma/jasmine are much slower and more finicky)

• Frontend Maintenance & Discovery

  • DEPR-100 - deprecation and removal of old frontend libraries: frontend-auth, frontend-i18n, frontend-analytics, frontend-logging, frontend-base

  • DEPR frontend-component-site-header, frontend-component-site-footer

    • 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.

  • Fixing legacy frontend tooling

    • Anything more specific here?

    • e.g., running JS Tests locally - running single tests

  • DEPR old frontend pages (on DEPR backlog)

  • Frontend Discovery

    • Existing technologies in use across pages

    • Surveying the Open edX ecosystem on their use of Comprehensive theming

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

• Shopping cart deprecation with Diana

  • lessons learned, knowledge sharing on dead code, etc.