Re: Glibc release check-list

["Joseph S. Myers" <joseph at codesourcery dot com>]

[libc-alpha removed from CC again]

On Sun, 15 Nov 2009, Alfred M. Szmidt wrote:

>    Should the ports maintainers have a pow-wow to decide who gets to do
>    the honours and when?
> 
> I think that ports releases should be done in sync with glibc.  Users
> will become immensly confused if you have glibc-ports-2.42 that is to
> be used with glibc 2.11.

I think they should be done in sync *for features and symbol versions, not 
time*.  They can't be in sync in both ways without there being a period of 
delay when there are no sysdeps updates in libc that might require 
corresponding ports updates, to allow ports maintainers to catch up.  So 
if you want them also in sync for time, you need to persuade the libc 
maintainers to allow such a period for synchronisation when creating libc 
releases and release branches.

I certainly believe in an active release manager role (this does not need 
to be a single person, it can be people working together through community 
consensus) that does more than just managing a branch once it is created 
but consults with subsystem maintainers and other interested parties 
before the release and decides in cooperation what the right time is for 
releasing and branching - and such a role for libc would naturally involve 
working with people doing such things for ports.  I hope we can manage 
ports like that even without libc following the same method.  Such things 
as the analysis of status of individual ports that I posted 
<http://sourceware.org/ml/libc-ports/2009-11/msg00017.html> are intended 
to serve as examples of what I think good practice should be for both libc 
and ports, while Carlos's responses on HPPA status illustrate the 
subsystem maintainer side of things (without which the release manager 
side of things isn't very useful - consulting about release timing needs 
the people consulted to respond).

-- 
Joseph S. Myers
joseph@codesourcery.com