From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7586 invoked by alias); 31 Jan 2003 19:21:04 -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 7579 invoked from network); 31 Jan 2003 19:21:03 -0000 Received: from unknown (HELO piper.synopsys.com) (204.176.21.195) by 172.16.49.205 with SMTP; 31 Jan 2003 19:21:03 -0000 Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id h0VJKsL28411; Fri, 31 Jan 2003 11:20:54 -0800 Date: Fri, 31 Jan 2003 20:52:00 -0000 From: Joe Buck To: Tom Lord Cc: bkoz@redhat.com, gcc@gcc.gnu.org, mark@codesourcery.com Subject: Re: GCC 3.3, GCC 3.4 Message-ID: <20030131112054.C28125@synopsys.com> References: <20030130181313.7d3c5820.bkoz@redhat.com> <200301311025.CAA29000@emf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200301311025.CAA29000@emf.net>; from lord@emf.net on Fri, Jan 31, 2003 at 02:25:48AM -0800 X-SW-Source: 2003-01/txt/msg01802.txt.bz2 On Fri, Jan 31, 2003 at 02:25:48AM -0800, Tom Lord wrote: > 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. People on the SC are just volunteers, and have no power to make vendors do anything. As I've said before, the SC only has negative power: we can refuse to accept a patch, we can delay a release, we can bounce a maintainer. But we can't make anyone volunteer to do something. You appear to persist in the fantasy that some kind of "insurrection" is possible. Do what? Go on strike? > 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 :-) Vendors *are* paying: Red Hat is contributing resources, HP is funding Mark's RM efforts, Apple gave us the precompiled header stuff, and many others have contributed work. Your fantasy SC, which would have the power to fling real money around, would be far more of a vendor tool than the present SC (since we'd then be explicitly representing our companies and their interests). It might be nice to have more resources, but the economy is crap, in case you hadn't noticed. > 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. What? You think volunteers are such abundant resources that the SC is in a position to refuse contributions??? > 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. We pushed on getting 3.2 out in an attempt to re-unify the GNU/Linux world. This is more of a service to the users than having each vendor using C++ compilers with incompatible ABIs. GCC is not done just for its own sake: the users can't use it until we release it. We gave something up so as not to have a repeat of "gcc 2.96". I think that's a good thing. The consequence was that 3.2 wasn't a great release, but 3.2.1 *was*. > The "community" is a de facto employee of the vendors. The SC > has a role in negotiating compensation, not seducing volunteers. How can the SC negotiate compensation? It has none to give, and no power to demand any. We have release schedules because we think that this is a good way to do software development. However, these schedules are not set in stone; we will be more willing to slip them than a proprietary software developer with contractual commitments might be.