[haiku-development] Re: Finally deciding on a new source control system for Haiku

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 03 May 2011 20:55:01 +0200

On 2011-05-03 at 20:28:11 [+0200], Adrien Destugues 
<pulkomandy@xxxxxxxxxxxxxxxxx> wrote:
> 
[ ... ]
> My own experience with forks is that they usually end in more work than
> needed, confusion amongst the users, and more difficult bug and issue
> tracking. But maybe using a DCVS magically solves all of this ?
> Remember the core developper team is a small one. Tracking patches is
> already one of the big tasks, and the goal of the switch is to make it
> take less time. Increasing the amount of patches to handle is not going
> in that direction. Maybe the easier merging makes up for it ; maybe it
> doesn't.

It's unfortunate that Github has named that button "Fork" when it should have 
been "Clone". A fork intends to break off the heritage, while a clone is 
based on the original (remote tracking branch) and adds experimental changes, 
usually meant to be applied upstream once they're ready and work well (which 
they may never do, of course).

> Anyway, the current process for contributors is as follow :
>   a checkout the source
>   b hack around and get something fixed
>   c use svn diff to create a patch
>   d create a trac account
>   e report a ticket and attach the patch to it
> 
> The way I see it, a DCVS replaces c with something else. When using a
> dcvs alone, people have to either make a patch (which loses the point),
> or set up a clone of our tree somewhere else so we can get the data.
> This is not easier for them. Using github, this same step is replaced by :
>   * create a github account
>   * create a fork of haiku on github
>   * submit the work to it.
> 
> On the contributor side, this still isn't as simple as "svn diff".
> It may be interesting, if it also replaces steps d and e. But Idon't
> know if it does. Does github or gitorious offer a way to trac the forks
> that were made from Haiku ? If so, how do we know which ones are ready
> for merging in the mainline Haiku ? Are they ready ? Are they meant for us ?

You miss the real point here, which is that a DVCS allows you to update your 
local changes to stay in sync with the trunk easily. That's where svn sucks. 
As a result, patches get stale pretty fast and the required effort to 
maintain them is so high with subversion, that people don't bother. In the 
end, this means we lose potentially good patches.

> These are the questions I worry about : I'm ok with switching to a DCVS
> for the ability to work on separate changesets, to do more things
> locally before commiting to the central repository, the easier branching
> and patch tracking. Enough discussion was spent on that, and it's
> getting sorted out. Switching to a service like github, however, means a
> lot of changes, and I wonder if we can handle it with our long quality
> review process and our small developper team. Maybe we can first switch
> to a DCVS, then later see if we need to do more ?

Github/Gitorious will not become a part of the core project, but it is a very 
nifty way for all contributors (including core developers) to publically work 
on experimental features of Haiku. If someone doesn't want to use it, no one 
forces it upon him.

cheers,
        Oliver

Other related posts: