On Sat, Aug 20, 2005 at 02:26:26PM -0700, Thomas Bushnell BSG wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> > It's completely unfounded bullshit.
>
> Do you have a specific complaint? Or is every single sentence in that
> post "unfounded bullshit"?
Pretty much every sentence. I didn't want to go through because it's
rather offtopic here, but as you're requesting it:
" * Limited development speed: even with the best tools, a single
integrator can only achieve a certain level of throughput."
the whole point of the pyramid development model as we have in Linux is
obviously to delegate decisions where possible possible while having
a single point for policy decisions when it comes hard to hard.
" * Opinionated maintainers: it is a rare individual who is always
right. For instance, the mainline Linux kernel does not contain a
kernel debugger because Linus won't allow it. "I don't think
kernel development should be 'easy'. I do not condone
single-stepping through code to find the bug." [2]"
So what's the alternative? People with commit rights fighting each
other leading to breakups? I am a firm believer that in the end one
person should have the final say for a given tree. This obviously must
come with an easy way for anyone challeing that person to have an own
not discriminated against, which is something that CVSs in the style of
BitKeeper/arch/git/etc allow easily by not having a specific trunk.
" * Limited filtering: work done by (or approved by) an area
maintainer is only subject to review by the branch integrator, and
such review may be cursory or nonexistent. Of course, anyone can
review all the changes that go into a branch, but only two people
are in a position to say "no, this change does not meet our
standards; it cannot go in" and make it stick.
That's not true at all. Everyone is in a position to publically speak
up and say that a change is not okay. Obviously only the release
manager for a specific branch has the final say, but his job is to
listen to the right people. This is extremly important to avoid commit
wars where people back out others changes without enough discussion.
" 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)."
As soon as we actually had a release branch that was't a problem.
A stable internal API and ABI is not a "standard" in any traditional
sense of the word. It's a feature that's associated with a very high
engineering cost. One that's far too high compared to the benefits for
most free software projects - there's a reason none of the major free
software kernels keep a stable API/ABI. E.g. FreeBSD is breaking their
ABIs and APIs in the stable branches all the time and OpenBSD doesn't
even have stable branches except for security fixes, they have new
release every six month that completely break the API and ABI aswell.
> > Whether you prefer a pyramid or lots of commiters style organization
> > is pretty much a personal or rather community organizational issue.
>
> Yes, and Greg is saying that a pyramidal structure doesn't work well,
> and that bitkeeper doesn't really have many advantages unless you are
> using a pyramidal structure.
For one thing it has enormous adavantages over CVS or even SVN, as
having used bitkeeper for projects like that. Alone the feature of
offline development and coloberation without a central server is an
extremme productivity gain. Let alone the nice merge algorithms.
But again I think the pyramidal structure works extremly well for the
Linux kernel, it's actually very similar to the development model I know
that are used in development of extremly large in-house or propritary
software projects I've been involved with where normally every team
has a branch or two and these only get merged back by a gatekeeper
(which is usually a team of very few people) after extremly careful
review. It's not like the BitKeeper model is something that, the
concepts are more than 30 years old.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
