GCC 3.3, GCC 3.4

[Tom Lord]

       I think the longer gcc, as a project, goes on without an
       autobuild continuous regression checker, the worse off things
       will get. It was nice of Red Hat to initially support this
       effort, but it is obvious that this time is past as the
       regression checker is long dead. Somebody else will have to
       step up with the bandwidth, time, and machine to do this.


<stating the obvious>That problem isn't unique to GCC.  It's an area
that needs investment.  Of course, it's an area where generic
solutions can be developed that benefit not only GCC but other
projects as well.  And it isn't vast investment that's needed --
on the contrary, quite moderate, by industry standards.

The vendors (who are, I realize, organizations, not persons) need to
realize that patch flow, automated testing, and automation assisted
project management and release management are really important, worthy
of study and strategic investment.  There's plenty of evidence on this
list, for example, of the costs of neglecting such investment.  Heck,
there's even some evidence in the infiltration of kernel development
by BK.  Such investment would be a fine contribution to the community
and would reap commercial benefits to boot.


       Some of these frustrations are with the development process,
       and have nothing to do with you or the SC. Please keep in mind
       that I have the utmost respect for both you and the SC.

I echo your sentiment of respect.  I laughed when I read Mark's recent
apology -- whatever faults he has, he's doing far, far better than
most in similar positions.  GCC positively shines, to those of us who
care about quality.

But to say that these process questions have nothing to do with the SC
or the maintainers is, frankly, bullcookies.

A lot depends on GCC.  There is social responsibility to taking care
of GCC.  The SC bears that responsibility by virtue of having the unique
position to give it voice.  If the project is under-resourced in a
context where GCC is commercially important, and if the SC are truly
independent of the vendors, then they have leverage and ought to bring
that leverage to bare on the problem.  I recommend a little insurrection
against the vendors.

The commercial experiment of "what comes for free in free software" is
over.  We know the results.  We know what doesn't come for free.  We
know what needs to be paid for.  Labor and capital are distinct
parties, for the most part.  Pretending that isn't so does both a
disservice.  Mark himself, of course, is an exception that tests the
rule :-)

The SC ought to, both directly and through a RM, stop inciting
volunteerism for commerical purposes.  Volunteerism is for the
benefit of the volunteers and for the benefit of society as a whole.

For years, before there was commercial interest in GCC, there was no
pressure for release schedules that would accomodate the needs of
Apple, IBM, Red Hat or others.  There should not be now.  It is
_wrong_ for calls to change volunteer focus to bug-fixing to keep
things "on schedule" in a context where the schedule is, in effect,
imposed to accomodate the vendors.

The "community" is a de facto employee of the vendors.  The SC
has a role in negotiating compensation, not seducing volunteers.


"Hard rock miner,"
-t