This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: Glibc release check-list
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: "Alfred M. Szmidt" <ams at gnu dot org>
- Cc: Carlos O'Donell <carlos at systemhalted dot org>, Daniel Jacobowitz <dan at codesourcery dot com>, schwab at linux-m68k dot org, pasky at suse dot cz, libc-ports at sourceware dot org
- Date: Sun, 15 Nov 2009 18:50:44 +0000 (UTC)
- Subject: Re: Glibc release check-list
- References: <20091113142845.GS3708@machine.or.cz> <119aab440911130700y3e00672cwfa2c679de89a3eb5@mail.gmail.com> <E1N9FaZ-0008HI-A6@fencepost.gnu.org> <119aab440911140842u39c5967k9fd8a820cfce49ab@mail.gmail.com> <E1N9iDQ-0005gF-D6@fencepost.gnu.org>
[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