Build-Test-Release Biweekly 2021-02-15

Working Groups Build-Test-Release
1

Build-Test-Release Biweekly 2021-02-15

Here’s what’s been going with the release group since the last update.

(Which happened 3 weeks ago - sorry! - I figure it makes more sense to time these so they come out shortly after the meetup, instead of one week later.)

Koa.2 (and Koa.2a) tagged by the community

For the first time, an Open edX release was tagged by a member of the community. It didn’t go exactly as planned due to a native installation bug, but the tagging process itself was successful. So much so that the subsequent tag that included the fix, Koa.2a, was also tagged by a member of this group.

The whole experience has resulted in improvements to the release howto page, thanks to @nimisha’s hand in guiding us through the RCA process.

We’re on GitHub!

Even though the ADR wording is still under review, we’re now officially using the “Everything board” on our GitHub project to manage the group’s tasks, PRs, and issues. Thanks a bunch to @nedbat for creating the repository, and @BbrSofiane for populating it with the existing issues, carried over from the old Jira board.

The exact way we’ll use it is still in flux, but it’s looking like labels will let us prioritize, and milestones will help us target specific releases. Suggestions are welcome.

Roles and assignments

We’re gotten pretty serious about assigning critical roles to Built-Test-Release members, and I’m glad to report that we’re on track to fill them. The roles themselves are under discussion in this proposed change to the group’s README. Here’s the current snapshot for Lilac:

The idea is that whoever takes on the responsibility only has to hold it until the upcoming release. In this case, Lilac. And yes, multiple people can work together on a single role, and one can hold a role for more than one release if so desired.

Which is to say: there’s plenty of room to help, if you want to volunteer!

Supporting both edx/configuration and Tutor for Lilac

While work is still under way to whip the “Tutor ADR” into acceptable shape, we have to start thinking about what a release would look like if we do indeed accept it. For now, the idea is to support edx/configuration as usual, albeit announcing it as deprecated for removal in Maple. In Lilac, Tutor would be supported as an “official release candidate”, and as the sole officially supported installation method for Maple and beyond.

This would be, roughly, double the amount of technical work overseen by the BTR group as compared to Juniper. We’ll have to delegate properly to see this through. While @regis is likely to head the Tutor effort, we’ll need somebody to oversee the edx/configuration work in a similar fashion. Speak up if you’d like to help!

The Tutor ADR

As mentioned above, the “Tutor ADR” is still being reviewed. There are three pending issues, in various states of progress:

The Tutor maintainer’s program

@regis is still looking for more community comments to his proposed maintainer’s program. It would be great to get more reactions so we can reach a decision faster. Group members, what do you think? @Felipe, @sambapete, @BbrSofiane, @nedbat, @pdpinch, @Maksim_Sokolskiy and others: any objections, thoughts… anything? Please comment in the PR, if you’re so inclined.

Tutor at scale

I’ll be talking to @regis about this and amending the ADR with a condensed version of his testimony on running Tutor for so-called “large” installations.

Tutor as a devstack and support for master

We had a great pow-wow about this a couple of weeks ago, and it’s why I’m conflating the devstack and the support-for-master issues. In short, @regis has offered to build a proof-of-concept for master support in Tutor. Once that’s done, edX and the community will be able to better evaluate Tutor not only as a devstack, but as a way to deploy (and maintain) master in production.

Building a definite plan for Lilac

Over the next few days I’ll be whipping up a tentative timeline for Lilac and posting it either as an ADR, an addition to the README, here in the forum, or all of the above. This will help concentrate our efforts. (For instance, I intend to propose that the Lilac “feature freeze” happen a full two months before the actual release. That’s less than two months away!)

Postscript

That sums it up for now! Feel free to discuss below. Thanks for reading!

3 Likes
2

@arbrandes Great to see this - and thank you for the recap!

I’ve done a pass of review on Base ADRs, role definitions, and assignments by arbrandes · Pull Request #13 · openedx/wg-build-test-release · GitHub

One point which is more explicitly mentioned in the current thread:

It’s definitely good to allow multiple people to contribute on any given topic – but can we also prevent the diffusion of responsibility effect by having one specific person designated as the main holder of the responsibility on each role? There will be enough releases to allow us to rotate the roles over time, so everyone interested should be able to get the main role assigned at some point. And in the meantime, it will always be clear who is responsible for making each role’s duty happen, even if it’s through delegation.

1 Like