2023-10-23 DevX Meetup Notes

Start the Meet recording!

Scheduled Topics / Demos

• [Kyle] Communicating changes to code

  • To whom?

    • Developers of the same repo

    • PR reviewers

    • API users (includes: Python, JS, HTTP)

    • Distributors (maintainers of devstack, tutor, et al)

    • Site operators and admins

    • “Delivery-side end users”: Authors, instructors, support teams, researchers

  • What we have now:

    • DEPR tickets

    • (Conventional) commit messages

    • Mix of PR templates, often ignored

    • Sometimes: changelogs

    • Sometimes: package release notes

    • Release planning pages → Named release notes

  • Discussion

    • Changelogs could get flooded with changes, fire hose of info. Also rebase conflicts.

      • Scriv for avoiding changelog merge conflicts. Tutor has been using it smoothly for a release now

    • edx-platform commit freq - 5 or 6 a day

    • Why not just follow the commit log and filter for breaking changes?

      • Many/most changes can be breaking

      • Why vs how

        • Example

          • changelog: Fixed the redirect loop in

          • commit message: fix: fixes the loop which was happening because yada yada yada

      • How could we have found out about a breaking change ahead of time?

        • Integration tests

          • cypress-e2e-tests? 2U runs these regularly. Could Tutor?

          • We would need someone in charge of fixing these

        • Actively informing Tutor maintainers

          • A channel that Open edX devs post in and that Tutor maintainers listen to

        • Or just better use of conventional commits.

          • Educate better

          • Fewest things necessary. We are already using conventional commits, why not take advantage of them?

      • Regis is used to handling breaking changes from edx-platform.

        • but Nightly is different

        • Author would have known if they ran Tutor

        • Or if they had an easy way to test Tutor, or even a way to know that they could be breaking Tutor

      • Does devstack break?

        • Provisioning tests run on every commit

          • They do sometimes alert 2U to legit breaking changes

          • OpsGenie alert

        • Type of breakage: existing environments vs only new environments

          • Existing environments are generally noticed faster

        • Devstack breakage debugging

          • Generally in an internal 2U channel

          • Could it be made public?

          • Tentative yes

          • Possible problem: noise coming from the community into the channel

      • Channel of push notifications of breaking changes

        • And/or just actually use the exclamation points

        • ^ those could be automatically pulled into slack

• [Régis] Nightly gives me headaches. How to resolve rebase conflicts? Is there any such thing as pip install -e --option=nightly .?

  • Some changes are specific to Nightly

    • COMMON_OPENEDX_VERSION

    • etc

    • ^ we want to get rid of those

  • Most changes from Nightly need to be merged in to <NextRelease>

  • How do we avoid those Nightly-specific changes?

    • use extras_require – eg pip install -e .[nightly]

• [Becca] 2U will be trialing putting an edX.org IDA in devspace

  • Needs to be a containerized service. maybe discovery

  • devspace in a local minikube

  • Diana has been working on this

  • What the heck is it ?-Kyle

    • Kinda like a generic version of devstack

      • has stuff we’ve added to Tutor, like auto-mounts

  • Could this smooth the switch from Compose to kubernetes

  • k8s manifests are terrifying

Cross Pollination

• Tools/features/opportunities

• Tips and tricks

• Roadmap news

Challenges

• Each challenge should have a follow up action.

• If you have an idea for follow up actions, add it.

• Or if you aren’t sure, leave it blank.

• We’ll discuss all actions either way.

Successes

• DevExp wins!

• @Emad Rad fixed the humongous user_id bug that Becca as hitting

Suggested Action Items

Last Time:

This Time:

After the meeting…

• Make an agenda for next time (tip: copy this page).

• Axim: Paste in the Zoom link once it’s ready.

• Paste these notes and next week’s agenda in #wg-developer-experience