Build-Test-Release Biweekly 2021-01-25

Hi there!

This is a companion thread to the (now Bi)Weekly Meetup’s. It’s meant as an experiment in substituting one of the weekly meetups with a more asynchronous discussion.

With that in mind, please use it to post any bit of information that requires action or is otherwise pertinent to the group’s activities, but that doesn’t otherwise warrant a topic of its own. I’ll then try to distill the discussion into actionable items (such as creating new tickets, etc.).

I’ll kick things off every other week with an update to what’s been happening, and what are the plans for the near future. If I miss anything… Hey, it’s what this thread is for! Feel free to correct me. :slight_smile:

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? :slight_smile: 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. :slight_smile:

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:

  1. 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!

  2. 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! :wink:

5 Likes

Hi @arbrandes. Thanks for your role proposal.

Unfortunately, We missed the BTR meeting last Monday but watched the recording. Regarding the roles assignations, we would like to get involved in the release tester position, and I say “we” since I want my two Edunext teammates (@eric.herrera and @Neo ) to get involved as well in this effort. I’d be the visible head and responsible for the role, but they would collaborate with testing tasks if required.

I don’t think we’d have the time to take this release testing on, but we could start acquiring the necessary knowledge on how this process is being performed so far, this way we’d be ready for koa.3.

I therefore await your feedback dear chair :grinning: thanks for your attention.

4 Likes

@jhony_avella, this is absolutely fabulous news! And I mean it: we’ll need all the help we can get. Thank you!

And no worries about koa.2. I’ll ping you when we get close to koa.3, though. :wink:

2 Likes

Ahead of the BTR Biweekly catch up and in the spirit of being more asynchronous, here are some issues that need some love!

1 Like

Unfortunately no, I have not had time to work on this. Unless I’m mistaken, all that is needed is to backport the fix from the master branch.

Sorry I made a typo in the issue, it’s meant to be #10! And now that I think about it, it probably makes more sense to ping you on github and have your response there.

@arbrandes what is the best place to start writing down in a more detailed manner the responsibilities of the test release role? maybe confluence?

An additional place to consider is

BTR wg goals and roles won’t be lost here for sure.

I think @Maksim_Sokolskiy’s idea is the best. For the kind of information that doesn’t change all that often, putting it in the repo’s README is the way to go. I’m actually starting to write an ADR/PR for it right now. :slight_smile:

And here is the PR.

@jhony_avella, you’ll likely want to comment on the Release Testing Coordinator section of the PR.

Also, the more people that comment there the better, because then we can add you as assignees or reviewers to issues. :stuck_out_tongue_winking_eye: (@Maksim_Sokolskiy, couldn’t find you GH username, btw.)

Thanks a lot, @Maksim_Sokolskiy and @arbrandes. I already started the conversation in the PR