Development model/versioning stuff: Interesting essay on why decentralised versioning is a bad idea

[Mike Hearn]

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.

Alexandre has shown a strong preference for Arch being the future of 
Wines development, which basically implies a pyramid development model. 
So I thought this document would be of interesting.

thanks -mike

[Lionel Ulmer]

> 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.

Well, if you agree with the article, you are basically saying that Alexandre
should let other people commit to the tree. Another way to read the article
is to say that 'wow, BK is exactly that we need in Wine because it matches
exactly the way we work' :-)

Anyway, we already discussed this to death about one or two years ago.

Lionel

[Mike Hearn]

> Well, if you agree with the article, you are basically saying that Alexandre
> should let other people commit to the tree. Another way to read the article
> is to say that 'wow, BK is exactly that we need in Wine because it matches
> exactly the way we work' :-)

I never said I agree with it, just that it was an interesting 
perspective on the cons of pyramid development that I hadn't seen 
before. I don't have a strong opinion either way (for once ;).

Currently distributed development models are all the rage it seems so 
it's nice to have an alternate perspective.
> Anyway, we already discussed this to death about one or two years ago.

True :)

[Mike McCormack]

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