[TCLCORE] Re: Staged commits ([TCT] Welcome...)

[Jim I. <ji...@ap...>]

Don,

On Tuesday, August 29, 2000, at 09:51 AM, Donald G Porter wrote:

> Jim Ingham wrote: 
> > > I think that patches should in general be staged,  
> > > and posted publically before they are committed. 
>  
> D. Richard Hipp: 
> > Are there any counter-proposals? 
>  
> Actually I like this proposal.  My only concern is whether it 
> might keep development too slow.  So long as there are enough 
> maintainers committing changes to the various functional areas 
> of the code, that should not be a problem. 

With a maintainer & a backup maintainer, this has not bee a problem in the gdb world, and the Tcl code is much more clearly written than gdb, with lots fewer implicit dependencies, so the job should be easier for Tcl than for gdb.

>  
> It is important that the decision to commit or not to commit 
> each patch is ultimately left to one person, and we don't 
> burden every commit with some kind of voting procedure.  Everyone 
> can look,  everyone can comment, one person decides. 

This is sometimes the case, but in gdb & gcc at least, there are often patches that cross functional areas, in which case you have to get several people to agree.  But this is the correct thing, in fact, because it assures that the people who really know each area are looking at the impact of the fix.

>  
> In case this system does slow things down too much, let's not 
> forget the option of a less-Cathedral, more-Bazaar development 
> model.  We have the code in CVS.  If a commit breaks something, 
> we can always pull it back out.  The code releases will be 
> in alpha/beta for some time yet, so we can even modify or yank out 
> new features that turn out in practice to be a bad idea.  Sometimes 
> bad ideas only make themselves apparent when you try to work with 
> the changed code, not in a theoretical pre-commit discussion.  
>  

I am nervous about this for two reasons, one that you might not figure out something had problems till fairly far on in the process, and then there are new dependencies that have crept in on the change, etc...

Also, and this is the more important reason to me, the maintainer role is a very nice setup to encourage education about the overall design, and the particular coding conventions for the given project.  This has worked really well for gdb, and I have often learned alot both in the process of submitting changes to the reviewers.  The everyone commits and you fight out what breaks doesn't really have good opportunities for fostering new contributors...

Jim
--
Jim Ingham                                   ji...@ap...
Developer Tools - gdb
Apple Computer

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.