This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Maintaining 2.12
- From: Petr Baudis <pasky at suse dot cz>
- To: Roland McGrath <roland at redhat dot com>
- 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: Sat, 15 May 2010 01:30:11 +0200
- Subject: Re: Maintaining 2.12
- References: <20100512215941.0295E40403@magilla.sf.frob.com><20100513142934.GK16800@machine.or.cz><20100514014539.AA819400BE@magilla.sf.frob.com>
On Thu, May 13, 2010 at 06:45:39PM -0700, Roland McGrath wrote:
> > 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
> exactly).
I don't know exactly either what to do right now. I think I do know
exactly what to do once Ulrich updates version.h 2.12.99 - check if
he branched release/2.12/master and it's up-to-date wrt. master^
and push it out if not, possibly wait another day or two to wait for
things to settle down finally, then tag 2.12.1 and upload a release
tarball - that all should be fairly well covered by:
http://sourceware.org/glibc/wiki/Release
What to do _before_ the release branch and master part ways, well...
who knows. :-) As I tried to explain the last mail, I don't see it as
a big problem myself since I consider the release to be still in -rc
quality state while it dwells in master and I'm not in a hurry (or
really care about the tarballs of the -rc quality release being
published properly); so my approach would be "just wait silently".
If others see a problem, they are welcome to propose solutions and
procedures.
Ad who will volunteer to be the maintainer, I was prepare to open that
question when 2.12 leaves master, for precisely the reasons above;
I don't see a rush. Perhaps at some point, someone will really care
about being a maintainer (e.g. I'm very happy to be 2.11 maintainer
since it is important for SUSE, being in an enterprise distribution)
and will volunteer proactivel; at other times like now, we will look
around among ourselves when the issue becomes relevant to us (for me,
that is at the 2.12.99 time).
> 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.
I _think_ Ulrich made the branch the last time, but I'm not sure.
For me, the key event is the commit updating version.h to .99, marking
start of development for next main version. It seems common-sense to me
to wait if Ulrich also pushes the branch around that time or do it
ourselves if that doesn't happen.
> > 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.
That is the definition I had in mind; I used a way too overloaded word
here, sorry about that.
> > 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
I think it would be good to keep the tradition of keeping the release
branch in sync with master right up to version.h update to .99.
> * 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 agree; but I believe the process is clear, well-defined and hopefully
working for minor stable releases (we will hopefully confirm that with
2.12.2 now), just not for the major stable release. My argument is that
given the state of the major stable release, I simply don't think it is
a huge problem or one that should automatically be in competence of the
to-be stable maintainers.
However, there isn't too huge amount of work involved. If you think it
will be helpful, I will try to initiate the discussion about next stable
maintainer before the next main version is tagged, and suggest that they
prepare and upload the tarballs. It would be helpful if Ulrich just Cc'd
his announcement on info-gnu or it will be awkward to forward or quote.
> > 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.
It was in a P.S. to the 2.11.2 post.
--
Petr "Pasky" Baudis
When I feel like exercising, I just lie down until the feeling
goes away. -- xed_over