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