|| ||Linus Torvalds <torvalds-AT-osdl.org>|
|| ||Paolo Ciarrocchi <paolo.ciarrocchi-AT-gmail.com>|
|| ||Re: BK kernel workflow|
|| ||Sun, 24 Oct 2004 10:44:44 -0700 (PDT)|
|| ||Larry McVoy <lm-AT-work.bitmover.com>, Jeff Garzik <jgarzik-AT-pobox.com>,
Linux Kernel <linux-kernel-AT-vger.kernel.org>,
Larry McVoy <lm-AT-bitmover.com>, akpm-AT-osdl.org|
On Sun, 24 Oct 2004, Paolo Ciarrocchi wrote:
> Well, I'm not interested in having the list of all the bk trees used
> during the develpoment of a release.
> I was looking to the trees used by mantainers.
Well, not only is "maintainer" fairly fluid, as Larry said, even if you
accept the fact that things will change, there's the issue that
- I do _not_ want people to "own" subsystems. And that's not so much an
anti-maintainer issue (I _love_ maintainers), as more of a "conceptual"
issue. When people expect one person or one group of person to be the
only way to touch a certain subsystem, we have problems. I really
really want everybody (users, developers _and_ maintainers) to realize
that no code is an island, and work with other people touching their
And part of that is that I do not like codifying maintainership. Even
something as simple as saying "this tree is the xxxx tree" is in my
opinion _bad_. Yes, a lot of core development for subsystems happen in
some specific "subsystem tree", but every time that has turned into
something "exclusive", it's been a _major_ problem.
And yes, we've had that problem several times. People having CVS trees
for networking, sound drivers, and other special development
subprojects invariably ended up breakign and throwing away work that
happened "unofficially". And often the "unofficial" work is nearly as
important as the official one.
So BK helps this model, because the distributed nature of BK means that
you can have several pseudo-official trees _and_ totally unofficial
ones, and merging is automatic and basically impossible to avoid, so
the "official" tree never gets to drown out the unofficial work. But
despite that, I want to make people _aware_ that maintainership does
not imply total ownership, and that we don't have a "hierarchy" of
developers but a *network* of developers.
To make a long story short: I do not ever even WANT "official" trees.
Because it gives the wrong idea to people.
I don't know if you've noticed, but I try to encourage other people to
make their own version of _my_ "official" tree, and unlike pretty much
all other open source projects I'm aware of, the Linux kernel
development model has always encouraged things like the "Alan Cox" tree
or "Andrew Morton" tree or "Andrea Arcangeli" tree. Or all the vendor
Many other projects try to control "the one true tree". Linux never
really did, and for the last several years it's been a conscious
decision for me to _encourage_ people to do their own trees. Exactly
because I don't want people to think that there are any really official
trees. My tree perhaps comes closest, but even I don't expect to be the
"final word on Linux".
This keeps us all honest.
Second, and less fundamentally:
- Even if we had "official maintainers" (and at any one time, certain
sub-areas certainly tend to have pretty strong maintainership), those
maintainers tend to have pretty fluid trees of their own, and they
change pretty dynamically.
Look at how trees are merged, and you'll notice that several
maintainers did a special "merge these things for 2.6.9" tree that
contained the stuff that they wanted to push out quickly, and that I
merged for just that release. It was basically a "throw-away" tree that
got used once.
This happens all the time, and again, I _like_ it. It means that people
can react a lot more dynamically to what is going on. Again, having a
documented "list of trees" would not make this kind of thing
technically impossible, but it would foster the wrong kind of "mental
See what I'm saying? It all boils down to the fact that I really like
having a dynamic development model, and that I want to try to avoid
putting in mental road-blocks to that model. I want Linux development to
be fluid, and I think the best way to reach that goal is to make people
_think_ of it as being fluid.
It's the old "perception changes reality" thing. It's really true. How you
think about something quite heavily influences what you do.
Wow. That was deep. Time to go watch TV again.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
to post comments)