From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8994 invoked by alias); 27 Mar 2002 07:11:29 -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 8870 invoked from network); 27 Mar 2002 07:11:07 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 27 Mar 2002 07:11:07 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g2R7Aqm14617; Wed, 27 Mar 2002 02:10:52 -0500 Date: Tue, 26 Mar 2002 23:11:00 -0000 From: Daniel Berlin To: Eli Zaretskii cc: Tim Hollebeek , Tom Lord , , , Subject: Re: gcc development schedule [Re: sharing libcpp between GDB and GCC] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-03/txt/msg00274.txt.bz2 On Wed, 27 Mar 2002, Eli Zaretskii wrote: > > On Tue, 26 Mar 2002, Tim Hollebeek wrote: > > > > The approach I am suggesting is an evolutionary step beyond > > > the current practices and is quite consistent with the SC > > > development goals. > > > > The SC can and will be the judge of that. Until then, please make > > sure that your contributions to gcc meet or exceed your contributions > > to this list. > > Sigh. Another attempt to shut up discenting opinions instead of dealing > with them in a civilized and technical manner. > > If Tom's arguments are as grossly invalid as you indicate, there should > be no problem to show that with simple technical arguments. Could you > please do that? Sure. Tom has not shown how his approach differs substantially from the one that has been previously been attempted, or for that matter, the one that was in use that eventually led to the creation of EGCS. In fact, it seems exactly like the situation that led to the creation of EGCS, minus any political overtones/interpersonal relationships/etc that were incidental. This has been shown to not work. Why? Because it causes things to stagnate on branches, while attempting to meet the "high barrier" on the trunk. If you move the barrier lower, however, you also let in some of the changes that really weren't ready. In addition, it assumes there is no overhead associated with maintaining a branch (and let's not get into a discussion about arch or anything, which i have a weird feeling he's trying to drag this into, no offense to Tom or anything), and that the branches will be as instantly up-to-date as the trunk, such that merges are not difficult, and one can effectively insure that merging a branch will cause no problems. Sorry, but nobody is going to merge a complete rewrite of the C++ parser, for instance, to the head, without *any* difficulties whatsover. It would require so much Q&A it's not even funny, and you would still likely have problems, even with this massive amount of Q&A. Furthermore, raising the barrier effectively pushes away young and new contributors, because they'll never be able to get simple patches accepted without a large amount of work (which is needed to ensure the trunk is high quality). It'll likely turn them off to trying to do anything larger. Simple patches that haven't been heavily tested do not necessarily affect trunk quality in a meaningful way. If some minimal level of testing was performed on them, it is generally sufficient. Certainly, I would not have started working on gcc in an environment that Tom suggests. While I could probably keep my patches at the level he's asking for now, I could not when i first started out, and if it took 5000 revisions and regression tests before it would even be *accepted*, i would have just stopped caring and moved on. Lastly, It's also very difficult to have a single level barrier that always exists, that simultaenously allows possibly intrusive changes to be made, without causing the quality of the trunk to be lower. The current plan attempts to alleviate this by progressively raising the barrier over time. You'll note that most people doing fixes right now on the 3.1 branch are experienced gcc developers. People just starting out rarely sit for hours debugging single problems in an effort to get a high quality release. Theoretically, the model you want to use is that which simulatenously: 1. maximizes the productivity of your scarecest resource, while at the same time, enables others to evolve into the role your scarecest resource currently fulfills. (i.e. lets experienced developers get work done and new features done, while at the same time, not stopping people just starting out from getting patches in, learning, and growing as part of the community). 2. maximizes the quality of your releases, in order to give the users something to use that works. In Tom's model, 2 is more important than 1. The current model tries to balance it more. Trying to make a model that perfectly balances this is almost impossible in practice, since all the variables change over time due to external factors. One of my biggest peeves about most software management models and theories is that few times, if ever, has anyone knowledgeable about software development just sat and observed the process, day after day, without being a part of it. In effect, studied software developers like they study animals, or other groups of people. I've never seen a posting on a bulletin board requesting software developers for any sort of study. Maybe it's just me. This is all rambling at 2am in the morning, so if it makes no sense, ignore it. :) --Dan