Mike Hearn wrote:
http://web.mit.edu/ghudson/thoughts/bitkeeper.whynot
What are peoples thoughts on this? It's not (despite appearances) an argument against BitKeeper due to licensing concerns, but rather a short paper on why the author believes the "pyramid" patch/development system is a bad idea.
From the article:
"For Linux, the consequences of these limitations have been slow and unpredictable release schedules, poor stability of release branches, and a lack of important standards (for instance, no consistent kernel module ABI or even API within a release branch)."
I think that the above is incorrect... IMO:
* mainline linux kernels have not been unstable. Kernels released by distros, which are presumably done with multiple committers are far more unstable than that released by Linus.
* the kernel->user space ABI is extremely stable. The internal kernel ABI is not stable, because supporting 3rd drivers is not a goal of Linux.
The release schedule of the kernel is slightly irregular, but I don't think that it's holding back development.
The advantage of having a single maintainer is that it reduces the level of politics in the project. We follow Alexandre's goals, which I think are pretty clear and consistent. Multiple maintainers would have multiple goals, and thus create conflict. There's always the option to fork the project if you think that you have a better way of doing things, but nobody has successfully done that so far.
The current development model for Wine is achieving good results. I don't think there's any need to mess with it. CVS has it's problems (mostly for maintainers), but there's no better tool at the moment.
Mike