Re: [ANNOUNCE] glibc-2.10.1-pb1 released

[Roland McGrath <roland at redhat dot com>]

Boys, there's plenty of work for everyone!  I hope from here on we will see
less waiting for me to bless things and more just starting to do stuff and
communicating plenty about it so we always have time to react before our
toes would be stepped on.

We need a 2.10 release manager, and before long we'll need a 2.11 release
manager.  As the first release branch handled under this process (2.10) and
the first release actually planned and made in the new model (2.11), both
will have a lot more work to do than we would anticipate every average
cycle's release manager doing in the future.  Each release branch will
largely be a separate consensus lead by its individual manager, but I hope
and expect that these two releases will establish the model and set some
initial procedures and guidelines for future releases.

Release managers need to:

* Start one or more pages about their branch on the glibc wiki.
  The first person also has to start the top-level Releases page that
  should (eventually) cover, or point to other Releases/Foo pages that
  cover, how releases work for contributors, how releases work for users
  and bug-reporters, how releases work for packagers (whether actively
  cooperating or not), status of individual release streams, etc.

* Have a sourceware account in the glibc group.
  There are web forms to request this and if you can't figure out
  how to get it done, things are not going to work out for you here.

* Hack themselves and/or coordinate with Carlos and whomever about
  the non-wiki glibc web pages that might should say something about
  your release branch.

* Propose/state on wiki and mailing lists the specific procedures and
  guidelines for the release/X.Y/* git space, so people know exactly 
  how to collaborate.

Off hand, I would guess it makes sense for Petr to do 2.10 and Andreas to
do 2.11.  But it's not so much about me naming as it's about you doing.
As I've said before, being "the guy" is mostly about "buck stops with"
and not about "in charge".  Each particular release stream will always
primarily be a consensus of the interested.  For these first two in
particular, I hope that both of you will be actively involved in both
releases and in setting the standard for future cycles.

The person doing the things I've listed above, and everything else
consistent with the ideas about the process that I've described here
before, is the release manager, and everyone will know who it is.  
If nobody authoritative-sounding has said so by the time everyone else
knows who it is, chances are it's still them.


Thanks,
Roland