Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Jan 1998 17:21:11 -0800 (PST)
From:      Simon Shapiro <shimon@simon-shapiro.org>
To:        Mike Smith <mike@smith.net.au>
Cc:        current@freebsd.org
Subject:   Re: Commit Approval (was Re: Firewall in kernel? - Found it! )
Message-ID:  <XFMail.980112172111.shimon@simon-shapiro.org>
In-Reply-To: <199801122344.KAA00315@word.smith.net.au>

next in thread | previous in thread | raw e-mail | index | archive | help

On 12-Jan-98 Mike Smith wrote:
 
...

> I agree wholeheartedly that there is still plenty of room for 
> improvement; don't get me wrong on that one.  My objections to your 
> proposals have more to do with what seems practical in the context of 
> the current development procedure.

Agree.  I was thinking about it in a different context.  

> I was considering this point as well; being able to cluster a group of 
> commits would be essential.
> 
> Often you want to commit several sets of interrelated changes to widely 
> separated components in the tree; eg. consider changing a header 
> implementing a kernel interface (evil, yes, but let's consider it).
> 
> You want to change the header, and the code in the tools that consume 
> it.  You don't want to have to check out large slices of the tree, make 
> your changes and then commit the whole lot in one fell swoop.  Instead, 
> you commit the changes to each tool separately.  This is both a 
> convenience feature and also leads to more compact and relevant commit 
> messages.

But, in between these commits, the tree is, by definition, broken.

> In another case, imagine you have just made a minor commit to fix 
> something, and you make a typo.  Normal procedure is to immediately 
> fix the fix.

If you follow Julian's procedure, this would never happen.

> There's another situation where you have two developers; #1 commits 
> code that is a prerequisite for #2's work.  They may be on the phone to 
> each other, or whatever.  A 3-hour wait for vetting would really slow 
> that sort of collaborative work down.

In this case, developer #1 is the key holder, and #2 submits his/her
changes to #1, which is now responsible for the whole transaction.
Any other way, #2 may get there before #1 and break the tree.  Can also
``work'' the other way around.

> One more practical problem; count the number of commits in a day.  
> Multiply by 3 hours.  If you want to serialise everything, that becomes 
> a real issue.

This is where my superficial proposal really breaks.  Using the compiler
(and make) as a syntax checker is really bad.  They are thorough but very
slow and fragile.  Something better and faster is needed.  Sort of
super-xref.

 ...

>> 2.  You prefer accuntability to procedure.
>> 
>> I must admit that I accpt point 1 and agree with point 2.
> 
> I'd agree with point #2 in this case simply because I feel that 
> accountability is more effective.  If I could see how procedure could 
> be more effective I'd swap sides in an instant.

Nah,  procedure always gets implemented where accountability fails.
By its nature, procedure fails too.
 
...

> We seem to have a system which is working reasonably well.  There is 
> historical precedent for resistance to any sort of change under the 
> circumstances.  8)

Which is, in a way, a good thing.

----------


Sincerely Yours, 

Simon Shapiro
Shimon@Simon-Shapiro.ORG                      Voice:   503.799.2313



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.980112172111.shimon>