On 02-May-11 10:00, Simon Taylor wrote: > 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 agree with the point about Haiku's approach; it has been mentioned many many times on this list (or maybe it was the main Haiku list) that we don't want Haiku to fragment into a bunch of not-truly-compatible distros.
However, since the switch is inevitable, a requirement that each developer merge his changes into the master branch (rather than requiring every developer to pull branches from every other developer in order to get all the changes) would theoretically work.
One problem: how would we enforce it? How *could* we enforce it? The very point of a DVCS is that there is no central authority with that kind of control.
On the other hand, I suspect everyone with commit access wants to see the project succeed, and would probably cooperate with such a rule. And if someone was too busy/unmotivated/whatever to merge his changes, someone else who really wanted those changes in the master branch could merge them himself.
