git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Theodore Tso <tytso@mit.edu>
Cc: Jakub Narebski <jnareb@gmail.com>, git@vger.kernel.org
Subject: Re: "Producting Open Source Software" book and distributed SCMs
Date: Tue, 1 May 2007 17:45:20 +0200 (CEST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0705011734460.4010@racer.site> (raw)
In-Reply-To: <20070501152342.GB26093@thunk.org>

Hi,

On Tue, 1 May 2007, Theodore Tso wrote:

> On Tue, May 01, 2007 at 11:35:54AM +0200, Johannes Schindelin wrote:
> > > [...]
> > 
> > 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 you agree! I said that it is a philosophical, and not a technical 
issue.

> 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.

But why! Because Pavel is just ignoring reality. I always wondered why the 
work of Nigel was never considered for inclusion, even if it was clearly 
superiour from a usability view point.

And if it is usable, but not clean, then clean it up. Instead, Pavel seems 
to never even have considering casting his planet sized ego aside and 
admit that his work is just not up to par with Nigel's, and start to 
clean up suspend2.

So in that case, I am even _more_ happy that forking is so easy, because I 
did not _have_ to suffer all that much from people who cannot enter my 
flat because their head does not fit through the door, but I could just 
happily use suspend2 and be fine.

BTW the same goes for Reiser4, which is quite fast and flexible, and I do 
not care at all about the ardent discussions around it.

> 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.

I refuse to get involved in such a sophistic (not to be confused with 
sophisticated) discussion.

I am _only_ interested in the technical side. Philosophical discussions, 
while fun when not taken too seriously, _can_ take all the fun out for me 
when the participants get too religious about their beliefs. So please, 
keep me out of them.

Ciao,
Dscho

  reply	other threads:[~2007-05-01 15:45 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-29 23:20 "Producting Open Source Software" book and distributed SCMs Jakub Narebski
2007-05-01  9:35 ` Johannes Schindelin
2007-05-01 15:23   ` Theodore Tso
2007-05-01 15:45     ` Johannes Schindelin [this message]
2007-05-01 18:30   ` Jakub Narebski
2007-05-01 23:13     ` Linus Torvalds
2007-05-01 16:15 ` Linus Torvalds
2007-05-01 22:27   ` Jakub Narebski
2007-05-01 22:45     ` Linus Torvalds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0705011734460.4010@racer.site \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=jnareb@gmail.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).