From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20788 invoked by alias); 27 Mar 2002 17:00:02 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20704 invoked from network); 27 Mar 2002 16:59:55 -0000 Received: from unknown (HELO cygnus.com) (205.180.230.5) by sources.redhat.com with SMTP; 27 Mar 2002 16:59:55 -0000 Received: from porcupine.cygnus.com (cse.cygnus.com [205.180.230.236]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA09560 for ; Wed, 27 Mar 2002 08:59:04 -0800 (PST) Received: from porcupine.cygnus.com (law@localhost) by porcupine.cygnus.com (8.11.6/8.11.6) with ESMTP id g2RH1tb04294; Wed, 27 Mar 2002 10:01:55 -0700 To: mike stump cc: lord@emf.net, gcc@gcc.gnu.org, gdb@sources.redhat.com Subject: Re: gcc development schedule [Re: sharing libcpp between GDB and GCC] Reply-To: law@redhat.com From: law@redhat.com In-reply-to: Your message of Wed, 27 Mar 2002 07:17:27 PST. <200203271517.HAA22671@kankakee.wrs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Mar 2002 09:00:00 -0000 Message-ID: <4293.1017248514@porcupine.cygnus.com> X-SW-Source: 2002-03/txt/msg00282.txt.bz2 In message <200203271517.HAA22671@kankakee.wrs.com>, mike stump writes: > flow out of their, well, uhm, because they are god, rather, because we > have seen them make the hard choices before, we have experience with > how they make them, and we have in the past agreed with their manner > and style. Right. And in a similar manner, we support those developers who we see consistently providing high quality designs, code, etc. When we see that happening we give those developers more and more freedom and eventually they turn into a Richard Henderson, Mark Mitchell, Jeff Law, etc. > To overcome this obstacle, you will need to either come up with ideas > that are obviously better to us that we agree with, or to put in > enough face time for us to know how you make choices. Right. Ultimately it comes down to building a certain amount of trust between the new developer and the older developers. Building that trust usually happens as the new developer submits quality analysis, designs and code. It may seem odd, but there was a time when each and every one of the key developers today had to go through the same process of building the trust of the older developers. In some cases that process actually happened nearly a decade before we even had a steering committee. > Also, ideas are free... Or put another way, ideas are a dime a dozen. > We can all come up with many ideas, the problem isn't one of coming up > with ideas, it is finding the resources to implement them. Amen! From my personal experience, that is really the kicker. And in fact, changes over the last few years in my personal and professional life have severely limited how much I can be involved in the day to day development of GCC. I contribute when I can, but the torch has largely been passed along to others. One of my key goals when we started the EGCS project 5 years ago was to build a self-sustaining project. It's been a joy to watch folks like Mark, Richard, Bernd, Benjamin, Gerald, David, Alex, Jan and a host of others pick up where I left off and continue to move the project forward as I stepped away from the daily grind. I'm sure that some of the key folks today will move on in the future, but hopefully we've put a system in place by which new developers are continually brought into the fold. > It has been that, it now that, and will always be that. If you increased the > value of your contributions to include the resources to implement > them, and yes, you can implement any idea you want... If you want a > SC committee that collects money from companies, you can always create > one, using anybody you want, using any rules you want. Just do it. > You don't need anybodies permission or acceptance. Right. One of the core ideas when we started EGCS was that folks contribute based on their abilities. For some that means they work on the internals of GCC, others deal with web pages, other deal with political issues, others deal with documentation, testsuites, etc etc. If someone's skill is finding money and managing dispersal of that money to foster development of key technologies, then, well, we'd welcome that. But we're not necessarily going to re-focus the steering committee or the developers to perform those tasks. jeff