Running Open edX on master with Tutor Edge

As part of the Blended Project (BD-43) sponsored by edX, I am tasked to get Tutor to work with the master branch of Open edX. Eventually, the goal is to offer a first class development environment for Open edX on the master branch. To do so, I propose to maintain an “edge” branch in the Tutor repositories. This proposal is put into words and code in this preliminary PR: Add tutorials to docs, and pave the way for the edge branch by regisb · Pull Request #494 · overhangio/tutor · GitHub

Currently, the edge branch is mostly based on top of this PR, with just one additional commit: GitHub - overhangio/tutor at edge

I’ll be happy to discuss this topic asynchronously here, but also in person. What do you think @maintainers?

2 Likes

@regis Thanks for working on it. This is a much-needed feature from Tutor. :slight_smile:

But, would it make sense to have the “dev/master” branch work with Open edX “master”. AFAIK, the current devstack actually has branches for each Open edX release. Will Tutor support developing on a release master branch? for example, “lilac.master” etc? If that is part of the plan then having “dev/master”, “dev/lilac.master” etc branches would be better than only one “edge” branch.

Good question, I have thought about that. My idea of the master branch is that it should be the branch that most people actually use, and running the Open edX release is what most people are using Tutor for (and will keep doing in the future). In the devstack (and other repos), we make separate branches for each release because the maintainers of the repos (aka: edX) don’t actually run the releases. The case is very different with Tutor.

An alternative solution I have considered is to name the “edge” branch with the next release. For instance, the edge branch would be named “maple” until the actual release of Maple, after which edge development would be moved to the Nutmeg branch. But this would be very inconvenient for edX developers, who would have to switch branches after every release.

During today’s BTR weekly meetup, I described Tutor Edge and Ned Batchelder commented that “edge” might have negative undertones at edX, for some historical reasons. “Nightly” is an alternative that he liked.

Hey @regis, just digging up this thread so I can better understand how master and nightly relate; particularly I want to grok why they are two separate branches instead of just a toggle available on master.

I can’t see that commit, but I assume it’s essentially the same as this one. As I understand it then, there are three differences between nightly and master:

  1. __version_suffix__ is set to "nightly" instead of "",
  2. OPENEDX_COMMON_VERSION is set to "master" instead of the release name, and
  3. nightly absorbs all of the breaking service upgrades, configuration tooling changes, etc. as soon as they are represented on the Open edX master branches; on the other hand, Tutor master remains compatible with the current Open edX release until the release has been cut, at which point nightly is effectively merged in

Differences 1 and 2 seem like they could be handled via a toggle. But difference 3 involves deeper and less-predictable changes that I imagine would require some messy templating in order to coexist on one branch, which is why you opted to make a separate nightly branch. Do I have that right?

You are exactly right :slight_smile: Basically, anything can change in the master branch: from the edx-platform settings to the Python version or the Ubuntu distro. We can see the huge amount of changes that are required whenever we upgrade from one release to the next. Managing these differences via a toggle would make everything extremely complex.

1 Like