2.95.3 (was Re: Removal of V2 code)

[Joe Buck <jbuck at racerx dot synopsys dot com>]

> Mark> I believe that in general the details of SC discussions are
> Mark> considered confidential in order to encourage frank exchanges of
> Mark> ideas among the SC members.  I could be wrong about that, but
> Mark> that's how I've always treated other people's SC postings.  If
> Mark> I'm right, that would make releasing any such archives
> Mark> inappropriate.

> What is it about release schedules that makes it important to discuss
> them secretly?  I think having a debate about whether to release
> 2.95.3 should happen in public.  In fact, the debate will probably
> happen anyway, whether the SC wants it or not.  I know we've discussed
> it several times on the Java list (mostly in terms of "I don't know if
> there will be one, since it is only discussed in secret").

It's OK to discuss 2.95.3 in public as far as I'm concerned.  So I'll
start it off, and hope I don't offend other SC members too badly.
(I'm usually the one who least knows when to shut up ;-).

It's also, as far as I'm concerned, OK to talk about what's been
discussed in the SC in general terms, as long as the topic isn't
sensitive (e.g. once in a while we have to deal with two people not
getting along, and after it's settled there's no reason to bring up
any name-calling that happened before).

The SC is charged with making final decisions, but certainly all
developers should have input -- as long as people understand that
releases don't happen by magic: we need real volunteers and there
are tradeoffs (that is, if we do 2.95.3 it is inevitable that 3.0
will be later).

We have a qualified person who has offered to run 2.95.3 if we do it.
Before we had that, there wasn't much reason to bring it up in public,
as it would just raise false hopes.  I'm not naming him here because
I didn't ask his permission.

We pretty much have consensus that we should at least do "2.95.2.1" --
a very minimal patch to work with glibc 2.2.  But the BSD folks and
others need a couple of other patches, suggesting that more should be
done.  It will be no use whipping something out quickly that just
embarrasses us all, so if we do more than 2.95.2.1 we need a substantial
testing effort to make sure we have no regressions wrt 2.95.2.

Inevitably folks will want some patches that can't go in.  One issue is
that we don't want yet ANOTHER incompatible C++ release out there, which
makes it very difficult, though not impossible, to fix the Linux-specific
vtable thunks bug without breaking link compatibility (unless someone has
a cool trick I don't know about).

Another issue that some on the SC have expressed worries about is whether
2.95.3 will cause developers of front ends or back ends that haven't been
fixed to work with the planned 3.0 changes (e.g. new C++ ABI, GC) to lose
their motivation to quickly fix the problems, meaning that either 3.0 will
taken even longer or then we'll be asked to support two parallel chains of
development going forward (2.95.4, etc).