I like the idea of "timeboxing" the RM to 3 months or so, but that doesn't really seem to be how it works. You basically volunteer for a release, then you're the RM for however long it takes to get that release out, whether it takes 2 weeks or 4 months. So your commitment basically boils down to the quality of master at the time you volunteer to cut the next release. If the branch contains many unknown critical bugs or new features that aren't feature-flagged at that point in time, your commitment will be much greater. The best way to reduce the amount of unknown critical bugs in any given release is to use feature flags and release often, so I think the best way to reduce the RM burden is by trying to do that as much as possible.
Also, it seems like most of the overhead involved in being the RM is just ramping up and learning the process (I had never used Subversion before), so it would kind of seem like a waste if you spent all that effort learning the process to just do a single release. So, maybe first-time RMs should be on the hook for at least 2 releases just to make sure they've been able to repeat the process at least once, then if we start cycling back through second-time RMs they would only be on the hook for 1 release. That seems like a win-win to me because it would mean we're not only releasing more often but also reducing the RM burden, increasing the likelihood of volunteers. The bigger a release gets, the more hesitant I would be to sign up as its RM. - Rawlin On Tue, Apr 21, 2020 at 7:36 AM David Neuman <[email protected]> wrote: > > The reason we used to have an RM for the whole life of a major release is > because we used to cut a single release branch and then build all of the > releases off of that. We would cut a 2.x or 3.x branch and then create a > tag at the 3.0 release. We would then backport whatever changes we wanted > in 3.1 to the 3.x branch and then tag 3.1 from there. This meant that a > single RM "owned" the branch for the duration of the Major release. > Since we are moving to a model where we are cutting from master for each > release, I think it makes sense that we could, if we wanted to, have a > different RM for each release whether it is major or minor. > > Whether or not we get enough volunteers still remains to be seen, I hope we > will :) > > So, +1 from me. It seems reasonable on the surface. It's been a long time > since I have had to RM though, back to the incubator days, so hopefully > some of the more recent RMs (Rob, Derek, Rawlin) can chime in and let us > know if we are missing something obvious here. > > > Thanks, > Dave > > On Mon, Apr 20, 2020 at 12:46 PM Jeremy Mitchell <[email protected]> > wrote: > > > For the last 2 major TC releases (3.x and 4.x) we've been appointing an > > open source release manager for the entirety of the major release: > > > > 4.x - Rawlin > > 3.x - Derek > > > > IMO this can be a lot of work if there are multiple minor releases inside a > > major and can be quite a lengthy commitment for one person (sorry Derek and > > Rawlin). How would everyone feel if we instead appointed release managers > > for each release (minor or major)....and if we aim for quarterly releases, > > this will limit the commitment to 3 months for a RM. The lower commitment > > may also help in finding volunteers. > > > > Also, each release (major or minor) has it's own branch derived from > > master, therefore, there's no reason you can't have different "branch > > owners" of (for example): > > > > 5.0.x > > 5.1.x > > 5.2.x > > > > (fyi, a RM must be a TC committer) > > > > Thoughts? > > > > Jeremy > >
