Re: gcc development schedule [Re: sharing libcpp between GDB andGCC]

[Daniel Berlin <dan at dberlin dot org>]

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