This is the mail archive of the
mailing list for the glibc project.
- From: Petr Baudis <pasky at suse dot cz>
- To: roland at redhat dot com, schwab at redhat dot com
- Cc: libc-alpha at sourceware dot org, ams at gnu dot org, carlos at systemhalted dot org,joseph at codesourcery dot com
- Date: Thu, 13 May 2010 16:29:34 +0200
- Subject: Maintaining 2.12
(Manually quoted on libc-alpha where all libc hackers like me can
> What I'd hoped is that by this cycle we'd have a 2.12 branch
> maintainer stepping forward at release time and not only after the
> fact, and that branch maintainers would take on the responsibility
> of doing tarballs and GNU release procedures.
I thought based on our current process that we step in only at the point
when Ulrich branches off and marks master as 2.x.99. As long as the
branch is not forked yet, Ulrich still has full power over the branch
and the stable branch restrictions don't apply. Even any other kind
of bugfix-only policy does not apply yet (e.g. getent -i support
was added after 2.12 was tagged).
Perhaps I was mistaken, but currently we don't even know how near a
release is (other than guessing by larger amount of NEWS updates).
I also frankly just don't feel very motivated packing a tarball for
the initial release when there is invariably going to be a lot of random
commits on top of it yet; I feel much more comfortable tagging and
releasing .1 very soon after the branch gets finally forked; that
release finally can have some guarantees about having bugfix-only
updates from then on, and all the other usual stable branch stuff.
In other words, in my mind the initial release feels more like what
other projects call a -rc, effectively. And since we now seem to have
some process to maintain the branches afterward, I don't even think
it's a real problem (worth arguing about, that is).
I already asked Andreas if he wants to maintain 2.12 earlier this week
- if not, I will happily step in.
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over