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