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.
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:
- Group chair: @arbrandes (yours truly)
- Release managers: @nedbat and @arbrandes
- Release testing coordinator: @jhony_avella (tentative) and @Maksim_Sokolskiy (also tentative)
- Release documentation expert: @nedbat (looking for a replacement - still trying to convince @pdpinch )
- Bug triager: @BbrSofiane
- Community liaison: N/A
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!)
That sums it up for now! Feel free to discuss below. Thanks for reading!