Re: The direction linux is taking

[Larry McVoy <lm@bitmover.com>]

On Sat, Dec 29, 2001 at 10:58:27PM +0000, Alan Cox wrote:
> > > Wrong.  Most patches are independant, and even touch different functions.  
> > 
> > Really?  And the data which shows this absolute statement to be true is
> > where?  I'm happy to believe data, but there is no data here.
> 
> I rarely get clashes in merges with either 2.2 or with 2.4-ac when I was
> doing it. Offsets from multiple patches to the same file happen some times
> but its very rare two people had overlapping changes and when it happened
> it almost always meant that the two of them needed to talk because they were
> fixing the same thing or adding related features.

So that means that pretty much 100% of development to any one area is being
done by one person?!?   That's cool, but doesn't it limit the speed at which
forward progress can be made?  And does that mean for any area there is only
one person who really understands it?

I'm not sure that you want single threading of development to be something
enforced by your development process, and that's what it is starting to 
sound like more and more.  Isn't it true that a lack of merge conflicts
means that there is no parallel development in that area?  

We have lots of commercial customers using BK on the Linux kernel, they
are doing embedded this and that.  The rate of change that they make is
much greater than the rate of change made in the Linus maintained tree.
I'm not saying it's good or bad, it's just different.  I can say that
merging is a huge issue in commercial shops.  It's interesting to hear 
that it is not in Linux.

Some sociology guy with a CS background should do a study on this and 
explore the differences.  Is fast change better?  Is slow change better?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm