Re: gcc 3.5 integration branch proposal

[Daniel Jacobowitz <drow at mvista dot com>]

On Mon, Jan 12, 2004 at 03:49:11PM -0800, Mark Mitchell wrote:
> On Mon, 2004-01-12 at 15:42, Geoff Keating wrote:
> > On Jan 12, 2004, at 11:22 AM, Mark Mitchell wrote:
> > 
> > > I'll make you a deal -- if you will commit to fixing five Bugzilla
> > > regressions between now and January 31st, and five more after the 
> > > branch
> > > is made, then I'll create the branch on January 31st, come hell or high
> > > water.  Deal?

All you're going to get from an offer like that is lower-quality bug
fixes.  It's not motivation, it's a deadline.

> > I think January 31 would be too long to wait, sorry.
> 
> No counter-offer? :-)
> 
> By the way, there's no question that there will be chaos when we finally
> do branch, and everyone starts putting stuff in for 3.5.  That's
> actually what's supposed to happen in Stage 1. :-)
> 
> I completely agree with Phil, however, that creating a proxy-mainline is
> inappropriate.
> 
> Apple (and some other vendors, including CodeSourcery) is in the
> position of doing its own release management and bug-fixing based on
> various versions of GCC.  Therefore, having high-quality FSF releases
> may not make much of a difference to Apple; Apple doesn't use it
> directly anyhow.  (Of course I do not know what Apple's management wants
> in this respect, nor do I know what your personal motivations might be,
> independently of your Apple employeeship.)
>   
> These releases, however, are FSF releases, and they should be of the
> same high quality as the FSF releases for other packages, such as Emacs
> or GNU Awk.  Unless the SC says otherwise, of course. :-)

"Same high quality"?  I know you're aware of them, but you might want
to revisit the reasons that _no vendor_ I know of in several years has
shipped an FSF released compiler. Even Debian, which is chronically
short of the talented manpower required for compiler development, ships
fifteen hundred lines of GCC patches plus a bleeding edge 3.3-cvs
snapshot last I checked.  The people with real budgets, like SuSE and
Red Hat, have orders of magnitude more changes.

I suspect the primary users of the release tarballs are roll-your-own
developers (mainly either embedded or need-a-newer-C++) and large site
installations (universities, corporate, etc.) who have a stable
existing OS with an older compiler.

Obviously we want higher quality releases.  But now that CodeSourcery
is doing the exact same thing as all other vendors, I'm sure you can
see why it happens, and holding off releases isn't going to help
anything.  My utterly unqualified instinct says that postponing the
release branch isn't going to help, since developers and vendors have
absolutely demonstrated their willingness to work outside of the trunk.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer