Potential New CC Role/Access: Named Release Manager

Working Groups Core Contributors
1

Hi all,

I want to propose a new role, which already exists in the BTR group, of Release Manager. Normally this has not been a CC role; I’d like to formalize it so we can unblock the group by giving the Manager write access to various code repos. This is needed in order to cut new branches and manage merging patches into release branches. Historically, edX - then tCRIL - has needed to be fully available to temporarily grant this write access then remove it. That is an impediment we’d like to overcome. Granting full write access without supervision requires the person have a Core Contributor agreement on file with tCRIL.

Specification

This role would be elected by the BTR group, as is currently done - and as part of the election, a nomination thread is put in this forum with the clear indication that BTR approves the choice. I would advocate for a shortened 1-week review period because BTR has done the vetting already and this election is often just-in-time for a new release.

Upon election to this role, the manager would be placed into the Community Release Managers GitHub group, with write access to all the repos contained in the current release. They would remain in this group until a new Release Manager is selected; they may choose to stay in the group if they are continuing to act as Release Manager alongside the new person.

Concerns

One wrinkle is that with write access to all Named Release repos, a Release Manager has the technical ability to merge in pull requests to a repo’s master branch without actually being a Core Contributor to that repo. There would need to be a level of trust with the new Manager that they would not merge to master (only to named release branches) unless they are also an explicit Core Contributor to that repo.

Another concerns the duration of the CC membership. Release Managers should feel free to resign from the Core Contributor program when their tenure is complete. If they do not, they will need to find a new role to fulfill.

Proposal

I would like to both propose this role and nominate @mtyaka, the current BTR release manager, for this new position. Matjaz has been a contributor to the project for a long time and is currently already a Coding CC with access to the edx-platform, cs_comments_service, configuration repos. He joined the program in November 2021. His GitHub is found here: mtyaka (Matjaz Gregoric) · GitHub

Comment Period

The comment period will end in two weeks, Thursday 10 November.

7 Likes
2

This sounds great to me, and I of course I support granting @mtyaka this new role :+1:

Just one clarifying question around this bit:

I assume you are saying that outgoing Release Managers should resign from the Core Contributor program if they weren’t already active (or willing to become active) in another CC role, right?

For example, Matjaz is already a Coder, so as long as he remains an active Coder, I imagine he would still remain a Core Contributor even after he is ready to step down from being Release Manager.

3

Same here, this seems like it reduces friction and I support @mtyaka in this new role. :+1:

4

Makes total sense to me, and I support @mtyaka for this as well.

5

This makes total sense and I clearly support @mtyaka nomination.

6

That is correct. I wanted to be explicit that it would be OK to get this CC role and only be a CC for six months. If you’re already a CC I’d expect you’d want to continue in your original role (although anyone is allowed to resign as CC at any point - I’m not sure we’ve ever made that super clear). I would also expect that exemplary performance as Release Manager CC might yield a nomination for a new role.

1 Like
7

+1 for the role as described, and @mtyaka as the recipient!

8

I am in favor of the role and @mtyaka for it.

We actually have other options than full write access that will let the release manager merge pull requests. There are actions in some repos (such as edx-platform) that use a shared workflow that will merge pull requests to the open-release/*.master branches if the release manager adds a comment instructing it to.

There are some problems with it though:

  1. The workflow has a hardcoded list of people who can trigger the action.
  2. The actual syntax for triggering the action has always been confusing, and no one can remember how to do it.
  3. I haven’t checked, but I think the action is not uniformly available in all release repos.

Maybe full write access is the better option at this point though.

9

I support both the role and @mtyaka’s nomination for it. :+1:

10

@mtyaka will be a fantastic release manager!

:+1: to his nomination, and the establishment of this role.

11

I also support this, there are lots of backports/PRs to come!

12

+1 from me too! Thanks for handling the release btw @mtyaka :+1:

1 Like
13

It is done! Thanks everyone for your input.

@mtyaka has been added to the Release Managers group. Moving forward BTR will submit a Github Request - Access/Config to the tcril engineering team when a new Release Manager is elected to add permissions to that user.

5 Likes
14

Thank you @sarina and everyone else that was involved in proposing and implementing this change which will make release management easier.

I can see I now have merge rights on repositories under the openedx organization, but there are also some repositories from the edx organization that are part of the release, and I don’t have merge rights on them. These are the six edx repos that are part of the the Olive release:

edx/edx-e2e-tests
edx/testeng-ci
edx/frontend-app-ora-grading
edx/frontend-app-communications
edx/enterprise-access
edx/frontend-app-learner-dashboard

Would it be possible to grant access to these repositories as well?

15

Unfortunately we are only admins on the openedx org and can only grant rights to repos there.

@nedbat - what are your thoughts? If these are part of the release is there a reason they’re not in the openedx org?

16

They are in the edx org because we didn’t have crisp criteria when decoupling during the 2U acquisition, so they were left in the edx org. Or, they are newer repos, and we haven’t done a good job ensuring that new work starts in the openedx org. I think everyone agrees that repos that need to be branched for releases should be in the openedx org.

I’ve added @mtyaka to the “community release managers” team in the edx org.

2 Likes