On Tue, May 01, 2007 at 11:35:54AM +0200, Johannes Schindelin wrote:
quoted text
> > [...]
> > 
> >   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.

There's a confusion going on here between a "fork" meaning a branch in
the SCM sense of the word, and a "Project Fork" where there are two
camps competing for developers and users.  So for example, having
kerenl developers develop using branches which are then merged into
the -mm tree and then into Linus tree --- Good.  In the
suspend-to-disk world, where we have *three* separate implementations,
with two in the mainline tree, and one very popular one, suspend2,
with features that niether of the in-mainline implementations have,
and with Pavel constantly casting aspersions at Nigel because he's
splitting the development effort --- Not So Good.

I prefer to use the term "branch" to talk about a SCM and development
series, and to use the term "fork" to talk about the political/project
issues.  So for example, even though Ingo Molnar's CONFIG_PREEMPT_RT
patchset has been a very long-running thing, it is constantly getting
rebased against the kernel, and there is no expectation that this
would replace the mainline kernel.  That makes a code branch, and not
a fork.

So my suggestion is to let branches be branches, and to reserve fork
for when there is an attempt to compete for developer and user
attention.  That is more or less the general understanding of the two
terms, and trying to confuse the two only leads to confusion and a
general muddying of the waters.

Regards,

					- Ted
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html