Appointing TC Release Managers

[Jeremy Mitchell <mi...@apache.org>]

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

Re: Appointing TC Release Managers

[Jeremy Mitchell <mi...@gmail.com>]

yep, i get it, there's some ramp up for a first-time RM but hopefully the
RM process doc has gotten a lot better and should minimize the
learning curve -
https://cwiki.apache.org/confluence/display/TC/Release+Management+Process - and
we could always encourage first-time RMs to take a second release but
optional, of course.

Ideally, i think it would provide a lot of value if

a) we had a strict cadence (quarterly for example) to prevent slippage and
b) we did a better job of defining the scope of a release at the START
rather than the END (as best we can of course)

so something like this:

Q1 - release: 4.1, scope: X, RM: Rawlin, start: jan 1, end: march 31
Q2 - release: 5.0, scope: X, RM: ?, start: april 1, end: june 30
Q3 - release: ?, scope: X, RM: ?, start: july 1, end: sep 30
Q4 - release: ?, scope: X, RM: ?, start: oct 1, end: dec 31

on the start date: the designated RM should start the conversation (via
email) about what the goals for the release are. Maybe the RM uses
issues/milestone to "scope" the release at least for the "big" things.
on the end date: the designated RM cuts the release branch from master and
builds RC0 and starts the process of getting the release approved so they
can be done

the release version is determined by the scope of the release. if scope is
big/breaking, major release. if scope is smaller, minor release.

as rawlin said a RM is really time-boxed to 1 quarter (3 months) plus
however long it takes to get the release approved.

Jeremy

On Tue, Apr 21, 2020 at 11:12 AM Rawlin Peters <ra...@apache.org> wrote:

> 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 <da...@gmail.com>
> 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 <mitchell852@apache.org
> >
> > 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
> > >
>

Re: Appointing TC Release Managers

[Rawlin Peters <ra...@apache.org>]

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 <da...@gmail.com> 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 <mi...@apache.org>
> 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
> >

Re: Appointing TC Release Managers

[David Neuman <da...@gmail.com>]

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 <mi...@apache.org>
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
>