BTR Biweekly, 2021-01-25
Here’s a rundown of the past week’s release-related happenings, and what are the plans for the following days.
A Leadership change
@regis has given me the key to the… chair? Anyway, I’m now acting chair for the group until at least the release of Lilac. It was done via lazy consensus, so thanks Regis for putting it forward, and for everybody else for not objecting too strenuously.
Koa.2
As discussed on Slack today and a while back here, the intention is to come out with timed point releases every two months after a “major” one. And we’re coming on to the first two-month mark after Koa. So, Koa.2 on February 9th!
Replacing edx/configuration (a.k.a. the Tutor ADR)
I’ve finally been able to evaluate Tutor as a development environment for Open edX, and added it under Criterion 7 in the ADR. Comments are welcome - including from folks at edX, @nimisha.
Aside from that, there are two points that need a little more research and/or community feedback before the ADR can be properly put forward for approval:
-
The Tutor Maintainers program. @regis is looking for feedback from the community, particularly those that have already contributed to it in the past. Take a look at his proposal in the Tutor repository, and please comment on it!
-
How we want to suggest large deployments be handled. Will it be via tutor k8s
, via Helm charts… What? Given that edX seems to be going down the Helm route, @nimisha has offered to put me in touch with some of the engineers there - I hope to be able to gather some hints from them.
Help wanted
As @antoviaque likes to point out, just because I’m chair doesn’t mean I have to do everything. I tend to agree. With that in mind, I’d like to announce the following three positions are open - all of them subject to further specification pending your comments.
Bug triager (herder? farmer? tester?)
We need a Super Hero like @nberdnikov but for release-specific bug reports and, hopefully one day, drive-by PRs. Is the bug something that should be handled by the BTR group? Or would it be better reported somewhere else? Is the bug reproducible? You get the idea.
Release tester
Whoever takes this on will be in charge of coordinating the testing of releases, from the moment the feature freeze kicks in until the release is tagged.
Release manager
@nedbat will help us define this, but in essence, whoever takes this up will be in charge of actually cutting a release, from tagging git branches to entering it in the ChangeLog - once we have one.
Release notes officer
Precisely because there’s no Open edX ChangeLog, it is this volunteer’s job to read commit messages, digest them, and produce release notes in a timely fashion so that they can be released with the release itself (release, release, release). I won’t call it a thankless job because we’re all going to send whoever takes this up flowers and beer - aren’t we? - but it is doubtlessly a tough job.
Warning: incoming RFCs, polls, and ADRs
There’s lots that I’d like to make happen, and I’m going to need your opinion and support. Over the following two weeks (to start with) I’ll write up polls, RFCs, or ADRs - whatever’s appropriate - on some of the loose proposals I posted earlier. Do we really want a two-month feature-freeze? To move to Github issues? And so on.
Postscript
That’s it for now! Feel free to comment, correct, congratulate, deny, or ignore. Have a great week!