Re: Managing the 2.29.1 release

[Carlos O'Donell <carlos at redhat dot com>]

On 09/01/2017 10:41 AM, Joel Brobecker wrote:
>>   I want to decouple the technical aspects of selecting what goes into a
>>   release from the practical aspects of creating the release itself.  So
>>   the current maintainers will get to approve or reject patches for
>>   inclusion on the branch, whilst the release manager - Patsy for this
>>   one - will take care of the practicalities of testing, packaging,
>>   uploading the tarballs and updating the web sites.
> 
> FWIW, this is something we instituted for the GDB release. To be
> completely precise, the way we phrased is that the Global Maintainers
> are allowed to approve patches for the branch, but I (as both
> a Global Maintainer and current Release Manager) encourage
> the Global Maintainers to do the approval rather than having people
> depend on me for that. This is simply recognizing that very often other
> maintainers are better qualified than the Release Manager to assess
> the situation and decide. As Release Manager, I can step in and provide
> some feedback when needed as well as well. But outside of the purely
> procedural aspect of creating the releases, things have been working
> quite well without the Release Manager, and this means my role is
> mostly limited towards helping people decide what's blocking and
> what's not blocking.  I don't remember ever disagreeing with a Global
> Maintainer on a given patch.

While you write "without the Release Manager" it appears that you are the
defacto release manager, so you are present and making sure the process
moves smoothly. That's exactly the role a release manager should have.
Thank you for doing that!

The key take away from this kind of release manager role is that the community
needs to step up and help technically to make the release possible, reliably,
and robust. You need that support.
 
In glibc we always assign a release manager for each release, and they
follow a checklist and resolve the obvious conflicts that arise during
the release process. That conflict is mostly about getting maintainers
to review patches and agree upon what will or will not make the release.

I would also like to point out that with glibc the machine maintainers hold
the responsibility for reporting on the status of their ports! This has
been beneficial in splitting up the testing work for a release.

For reference the glibc process is documented in detail here:
https://sourceware.org/glibc/wiki/Release

And you can see the last release results here:
https://sourceware.org/glibc/wiki/Release/2.26

Thanks to Nick and Patsy for kicking off this work for binutils!

-- 
Cheers,
Carlos.