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

  • From: Adrien Destugues <pulkomandy@xxxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 03 May 2011 18:42:30 +0100


I would appreciate, if you didn't speak for all of us on topics we haven't 
voted on or otherwise found a consensus. At least for me improving the 
Trac/patches workflow is only a secondary goal. Having a better tool (that is 
less broken when it comes to merging and that sports all the nice DVCS 
features) is the primary goal for me.
Sorry about that, I felt it was the consensus when writing that mail...
Anyway, I think the concerns I raised are what started the discussion, but maybe I missed some parts. Of course, it doesn't prevent getting all the new features, but it needs some thinking on how to make good use of them.
Besides, I don't even think that patches becoming impossible to be applied has 
been a common problem. There are other Trac/features that would help a lot more 
with our patch workflow than a new VCS would (there was a GSoC application for 
improvements in that regard).
It happened to me multiple times, and reworking the patch is an annoying task which isn't actually getting any progress done. When applying a patch could be a one-click operation with the proper tools, this gets quickly boring.
The goal, however, is to keep our current centralized workflow, and only
use some DCVS features to ease things that were painful in SVN.
There have been a few discussions about the workflow, but beyond that most 
(all?) people seemed to prefer to continue having a central, official 
repository, I don't recall any specifics everyone has agreed upon. Definitely 
not that we don't want to use certain features of the potential tools.
That's only a start, I hope we will get used to the new features and find good ways to use them. But switching from our current workflow to a massively-forked one on github seems like a too big change at once.
[...]
We don't want people making easy forks, moving away from the current
server setup, or anything else. We want to keep the current setup as
much as possible, while still adding these improvements. Switching to
github would be a way too big move for that. It has a great risk of
going out of control.
I really wish you wouldn't speak for all of us. At least I don't see any "going out 
of control" risks. If we switch to git, I'd consider it inevitable that people would 
clone the official repository on GitHub, Gitorious, etc. and I don't see a problem with 
that. On the contrary, I'd even encourage a more open development.
This is not a problem per se, the question is, can we track all these forks and merge the changes which deserve it ? Or will one of the forks become more widely used because we can't keep up with the stream of patches from them ? On one side it's nice to see more development hapenning, on the other it's of no use if each patch lives in a separate fork and there is no easy way to merge them all.
Where we host the official repository is mostly a technical matter. I guess 
we'll have more flexibility hosting it on our own server. That doesn't mean 
that we couldn't have auto-updated clones on GitHub/Gitorious/...

Sure. But do we need them ?
On a personal note this time, I don't feel like thrusting another web service and think it's a bad move in the cloud computing direction. But maybe that's only me.

--
Adrien / PulkoMandy

Other related posts: