Managing the 2.29.1 release

[Joel Brobecker]

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

-- 
Joel