Re: [ANNOUNCE] glibc-2.10.1-pb1 released

[Roland McGrath <roland at redhat dot com>]

> This is now upstream.  IMHO glibc-2.10.2 should also contain:
[list of trunk commit ids.
Btw, I have in ~/.gitconfig:

[alias]
	l = log --pretty=oneline --abbrev-commit

and that is IMHO the nicest form in which to cite lists of commits.]

I'm glad to see this list.  I had been hoping to see Jakub's list a while
back when the latest release branch discussion started.  Unfortunately,
this has coincided with a present period of transition where Andreas Schwab
is starting to take over some Fedora glibc work from Jakub, so we have been
collectively rather distracted on the Fedora team, and I haven't had any
spare cycles to think about neglected glibc administrivia on the back burner.

It has been nagging at my mind to want to check the union of everybody's
list of trunk commit ids, and make sure the cherry-picks on the backport
branch are in original order of trunk commits (maybe can use "git rev-list
--no-walk --date-order" or something like that).  That is probably entirely
gratuitous anality.  Now that it's off my chest, I'll stop thinking about it.

I think that once Petr, Jakub, and Andreas are actively discussing the
details for the branch, that is sufficient momentum toward officialdom for
me to declare that this here is the proper maintenance of release/2.10/master
going on right now.  (I don't mean to exclude folks like Joseph and Daniel,
and indeed very much want them to be more involved.  But heretofore they
have not discussed specific details for what goes into this branch that I
noticed, just a vague intent to follow the branch if there is one.)

My preference would still be to have the nominal degree of formality where
we name an individual as "2.10 release branch manager".  This has less to
do with any formality about the actual git branch maintenance (everybody
can pull/merge from everybody else, and that will just hash itself out).
What I mean is someone who decides the nuts and bolts of things in
sourceware git (set release/2.10/* branch name space policy), handles files
on sourceware ftp, spends some time on the wiki pages about the branch, and
when the time comes shepherds the official GNU upload/announce processes.
This person is also on the hook for policing the details of the branch
(copyright issues, obeying branch policies, etc.), but that really just
means being the one person who pays enough attention to everything to catch
any mistakes quickly (I'm not worried about malice).

Off hand I feel like trying to draft Andreas for this.  
But he should speak for himself. :-)
I really want only to coax and not direct, to get the ball rolling
of a collaboration that doesn't ask me what to do.  (It's nearly 22 years
old now, glibc can move the hell out of my basement already!)


Thanks,
Roland