Versions Compared

Old Version 1

changes.mady.by.user Feanil Patel (Deactivated)

Saved on

compared with

New Version Current

changes.mady.by.user Tim McCormack

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  • OpenedX releases

    • Going from 4 months → 6 months

  • Waffle switches/flags/samples

    • Why we don't like them

      • It’s dumb that the configuration is in our database.

        • Hard to debug

        • Hard to manage/duplicate

      • There is now no validation or review before making a change.

      • Often they don’t have good docs on how to manage them.

      • Often don’t have many people who know how they’re supposed to work.

      • Even if we had manual review, review of django-admin UI is not as good as reviewing code or config.

    • Some reasons why waffle is nice.

      • Sometimes we want to roll-out low risk things and changing settings via remote config is WAY slower and has more overhead.

      • Really useful for quickly flipping and testing a configuration before ripping the flags out.

    • Things we’re doing that should help?

      • Toggle Documentation Improvements

        • Should this be required?

      • We could be reducing complexity of the waffle things by building/simplify better waffle base classes.

    • Other Notes

      • Making more abstraction layers on top of waffle/django might not be a great idea.

      • However if we are constantly fighting our flag framework.

  • Let pyupgrade switch %-formatting and {}-formatting to f-strings?

    • f-strings are usually easier to read, any objections to moving to this?

    • How does this work with translations?

    • is the "optimization" faster than both %-formatted and str.format or just one?

      • Jeremy thinks yes.

      • DaveO points out that string interpolation doesn’t ever seem to be in the critical path for perf, so don’t make that the primary concern.

    • Major re-format will cause downstream issues with people maintaining forks.

    • Feanil: What if we also run Black?

      • If we’re ruining the git blame anyway, may as well do it now.

      • Reasons not to do this:

        • Black diffs are much harder to read and might produce more merge conflicts in the future.

  • Open edX contributions:

    • What’s eduNEXT?

      • Open edX company based in Colombia, doing some blended development work for us

        • They’ve been to 7 of the 6 open edx conferences.

    • Do we merge any PRs from any open edx contributors? Or is there some flag that identifies the GitHub user that we can take contributions from?

      • No, we don’t just merge everything.

      • Bot will greet open source users and make sure they have signed a contibutors agreement. This can be used to spot open source PRs

      • You should review any PR before accepting it.

    • What is blended development and what is the typical workflow for blended development tickets? What are edXteams'/developers' responsibilities towards OpenEdx/blended development tickets?

      • Sometimes Blended PRs get auto closed, and devs don’t know why?

        • The PR is linked to a Jira ticket, if the PR is auto-closed it might have been because the Jira ticket closed.

      • Some engineers are getting tagged directly on blended tickets.

        • You should make sure your team is aware of it and that it’s tracked on your side. Blended projects might tag you because your team owns a repo being updated via blended.

    • Have more questions ask in the #openedx channel

  • Ownership

    • Different teams are treating ownership differently.

    • Some teams are treating ownership more loosely when it comes to upgrades than others.

      • Is this okay?

    • (Product management is not fully onboarded or clear on the implications of ownership either. Awareness and confidence in plans are unevenly distributed here - Marco)

  • Rebranding edX.org and its i18n implications - defered till next time.