Re: "Producting Open Source Software" book and distributed SCMs

From: Jakub Narebski <jnareb@gmail.com>
Date: May 1, 2007, 18:30 UTC
Message-ID: <200705012030.11747.jnareb@gmail.com>
In-Reply-To: <Pine.LNX.4.64.0705011057130.29859@racer.site>

Hi

On Thursday, 1 May 2007, Johannes Schindelin wrote:

Show 36 quoted lines

> On Mon, 30 Apr 2007, Jakub Narebski wrote:
> 
>> Linus has said that fully distributed SCM improves forkability:
>>
>> [...] 
>> 
>>   I think that "forking" is what keeps people honest. The _biggest_
>>   downside with CVS is actually that a central repository gets so much
>>   _political_ clout, that it's effectively impossible to fork the
>>   project: [...]
>> 
>> According to "Producting Open Source Software" it is very important 
>> feature for an OSS project.
>>
>> [...]
>> 
>>   Because a fork is bad for everyone (for reasons examined in detail in 
>>   the section called "Forks" in Chapter 8, Managing Volunteers, 
>>   http://producingoss.com/producingoss.html#forks), the more serious the 
>>   threat of a fork becomes, the more willing people are to compromise to 
>>   avoid it.
> 
> This is a lousy argument, IMHO.
> 
> Why are forks bad? They are not. But if you "learnt" that merges are hard, 
> they are.
> 
> It is a pity that so many people were trained in CVS, and keep thinking 
> some of the lectures were true, when they are no longer.
> 
> Forks are good. In fact, we all "forked" with CVS as soon as we began 
> hacking. Everybody who claims to never have started over from a fresh 
> checkout, or from an "update -C"ed state, is probably lying, or a bad 
> developer. Thinking about it, I believe that the difference between 
> forking and branching is philosophical, not technical. You can always 
> merge a fork.

IIRC Compiz and Beryl (fork of Compiz) plan to be merged. Both projects use git as SCM. We will see how this "merge a fork" will work.

In "Producting Open Source Software" Karl Fogel gives an example of GCC/EGCS fork, which resulted in "fast forward" merge (EGCS which was fork of GCC, became next version of GCC). Similar example is XFree86/X.Org fork; Linux distributions went from packaging XFree86 to packaging X.Org.

But for example GNU Emacs / XEmacs fork will never be merged, I think. So not always you can merge a fork - you can try, unless codebase diverged too much.

Show 9 quoted lines

>> Is distributed SCM better geared towards "benovolent dictator"
>> model than "consensus-based democracy" model, as described in
>> OSSbook?
>
> Not at all. I think the best example is kernel.org, where you find
> tons of forks. IMHO it is really helping the benevolent dictator cave
> into the consensus-based model, since forks can be preferred at any
> time. Hey, even switching from one to another upstream is just a
> git-pull away!

What is or is not a fork is a bit blurry in the world of distributed version control systems. Is a clone of repository a fork? I think that everybody would agree that it is not. Is for example *-mm tree a fork? I'd say not. But I'd say that Beryl is a fork of Compiz...

-- 
Jakub Narebski
ShadeHawk on #git
Poland