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

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Mon, 02 May 2011 11:38:14 +0200

Am 02.05.2011 11:00, schrieb Simon Taylor:
On 02/05/11 09:40, Daniel Pihlström wrote:
On Mon, May 2, 2011 at 9:58 AM, Axel Dörfler<axeld@xxxxxxxxxxxxxxxx>
wrote:
We can already have developer branches at github if we want to, and
everyone can already use git locally now.

I personally think that the actual benefit of github has more to do
with attracting developers to the project rather than for use by
developers who have already been converted.

Why would it attract new developers? It's really not hard to pull the
source from svn (or the git or hg mirror) and start hacking locally.

I'm not convinced it's an advantage to have it very easy to fork Haiku
online to a whole new online-accessible project. Haiku isn't a typical
OSS project, it's more a unified effort driven by the core team. Please
correct me here - but doesn't a git setup typically result in people
doing their work in their own forks, which can then easily get out of
sync with the master repo? Isn't that exactly the same problem that
happens with stale patches on trac? At least then they're in a central
place and we know about them, and they're not scattered around multiple
places on the web.

I guess I'm scared we'll end up with people saying on trac - "oh, you
want this bug fixed, then get haiku-ish-simon-fork-17 which has it all
working nicely. Note it isn't ABI compatible as I haven't pulled Ingo's
weak symbol stuff in...".

I know DVCSes are flexible and we just have to design our workflow, but
the usual git model seems much more fitting to the fragmented
development model of linux than to the more centralised approach of Haiku.

I haven't really formed an opinion on the advantages or disadvantages of a development workflow where we use github, but the one time I have encountered a forked project was when I was discovering the existance of the FFmpeg-mt branch, where some crucial code paths in FFmpeg, at least the demanding h264 decoding, had been made multi-threaded. This fork had exactly the fragmentation and irritation problems that are pointed out above. Why wasn't it already part of mainline FFmpeg? Was it buggy? There were rumours of it working most of the time, but not always. Was it being kept in sync with FFmpeg trunk and maintained?

Best regards,
-Stephan

Other related posts: