This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCE] glibc-2.10.1-pb1 released


  Hi!

On Thu, Jul 16, 2009 at 01:38:25PM -0700, Roland McGrath wrote:
> 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.

  That is so, except of course the RPC licence change.

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

  Great!

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

  Ok, I suppose Andreas already has experience with the GNU maintenance
stuff...

  This branch is fairly specific in that it's pretty much pure
cherrypicking, so how will we be doing this? Andreas, should I just
continue what I'm doing now with you pulling from me (I'm just getting
to a two-week vacation a week after this one), or will you do the manual
cherry-picking work yourself regularly with us just reviewing and
discussing which commits to choose? Using a first comes first commits /
request-pulls basis could get overly chaotic quickly I suppose.

  I'd still like to agree on the release criteria in the other
sub-thread.

-- 
				Petr "Pasky" Baudis
The lyf so short, the craft so long to lerne. -- Chaucer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]