From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1808 invoked by alias); 31 Jan 2003 10:25:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1801 invoked from network); 31 Jan 2003 10:25:51 -0000 Received: from unknown (HELO emf.net) (205.149.0.20) by 172.16.49.205 with SMTP; 31 Jan 2003 10:25:51 -0000 Received: (from lord@localhost) by emf.net (K/K) id CAA29000; Fri, 31 Jan 2003 02:25:48 -0800 (PST) Date: Fri, 31 Jan 2003 11:52:00 -0000 From: Tom Lord Message-Id: <200301311025.CAA29000@emf.net> To: bkoz@redhat.com CC: gcc@gcc.gnu.org, mark@codesourcery.com In-reply-to: <20030130181313.7d3c5820.bkoz@redhat.com> (message from Benjamin Kosnik on Thu, 30 Jan 2003 18:13:13 -0600) Subject: Re: GCC 3.3, GCC 3.4 References: <20030130181313.7d3c5820.bkoz@redhat.com> X-SW-Source: 2003-01/txt/msg01745.txt.bz2 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. 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