This is the mail archive of the
mailing list for the glibc project.
Re: Maintaining 2.12
- From: Roland McGrath <roland at redhat dot com>
- To: Petr Baudis <pasky at suse dot cz>
- Cc: schwab at redhat dot com, 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 18:45:39 -0700 (PDT)
- Subject: Re: Maintaining 2.12
- References: <20100512215941.0295E40403@magilla.sf.frob.com><20100513142934.GK16800@machine.or.cz>
> 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).
That logic is all fine enough by me. What I meant is that I'd hoped
that before the time that Ulrich made the glibc-2.12 tag, we would have
named the 2.12 release manager and everybody would know what the plan
was. That's manifestly not the case, since we have people asking each
other about tarballs and not knowing what's going on (even I don't know
It's no secret that the glibc release cycle is attuned to the Fedora
release cycle. (Currently that's fairly regular at about six months
with some slush back and forth. If Fedora's rhythms change
substantially in the future, then glibc might follow or might start
doing something different.) So in any given cycle one can consult
https://fedoraproject.org/wiki/Schedule and expect that the "Final
Freeze" date (often slipped a week after the original planned date, but
always indicated on the wiki) is a deadline Ulrich will intend to meet
(probably by only a day or three) for committing version.h/features.h
with the new number and making the main release tag. If potential
release branch managers are on the ball, they will have kibitzed loudly
enough and scribbled visibly enough on the glibc wiki by then for
everyone to know who this cycle's manager is and how he plans to proceed.
It was never at all clear to me that Ulrich will or should make the
branch. I don't remember who did the actual push the last time and I
don't know whether Ulrich expects to have to do anything about it or
not. (FYI, I believe Ulrich may be having a busy week and we might not
hear from him for a few days.) It's my impression that Ulrich is
happier the less he thinks or knows about the whole branch management
and formal release part of the process. So I'd say it's for the
particular cycle's release branch manager (mediating the consensus of
distributor branch maintainers and other interested contributors) to
make branches and all that.
> 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'm not sure what definition of "a release" you have in mind. The
glibc-2.12 tag was made, so that's the first thing "the 2.12 release"
would mean to me. Other definitions are indeed probably far more
useful, but are as yet far from being obvious.
> 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).
That all sounds reasonable to me. I haven't noticed there being any
actual argument here, just expressions of confusion. Basically, I think
it is fine for the release branch manager each cycle to choose the
criteria and methods (delegate to whom, do it yourself, etc.) for:
* fork release/NN/something when from what
* make and sign canonical tarballs (of what numbering) published on sourceware
* push such tarballs to ftp.gnu.org
* make an announcement to info-gnu et al
I just want them to feel obliged to make it very easy, before, during,
and after such events, for everyone to figure out when and how they happen.
Right now, nobody seems sure about how or when any of those get done.
> I already asked Andreas if he wants to maintain 2.12 earlier this week
> - if not, I will happily step in.
If that was on the list I didn't notice it. Of course I am happy for it
to be done by whomever is enthused and committed to doing it.