From: Linus Torvalds <torvalds@osdl.org>
To: Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com>
Cc: Larry McVoy <lm@work.bitmover.com>,
Jeff Garzik <jgarzik@pobox.com>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Larry McVoy <lm@bitmover.com>,
akpm@osdl.org
Subject: Re: BK kernel workflow
Date: Sun, 24 Oct 2004 10:44:44 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0410241027320.13209@ppc970.osdl.org> (raw)
In-Reply-To: <4d8e3fd304102403241e5a69a5@mail.gmail.com>
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
subsystem.
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
trees.
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
landscape".
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.
Linus
next prev parent reply other threads:[~2004-10-24 17:45 UTC|newest]
Thread overview: 161+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <41752E53.8060103@pobox.com>
[not found] ` <20041019153126.GG18939@work.bitmover.com>
2004-10-19 16:06 ` Jeff Garzik
2004-10-19 21:33 ` Paolo Ciarrocchi
2004-10-19 21:38 ` Jeff Garzik
2004-10-19 21:54 ` Paolo Ciarrocchi
2004-10-19 22:11 ` Linus Torvalds
2004-10-20 7:35 ` Paolo Ciarrocchi
2004-10-23 16:12 ` Larry McVoy
2004-10-24 10:24 ` Paolo Ciarrocchi
2004-10-24 14:44 ` Larry McVoy
2004-10-24 16:44 ` Paolo Ciarrocchi
2004-10-24 23:32 ` Larry McVoy
2004-10-25 11:33 ` Matthias Urlichs
2004-10-25 11:46 ` Andrea Arcangeli
2004-10-25 12:29 ` Joe Perches
2004-10-25 13:39 ` Andrea Arcangeli
2004-10-25 15:14 ` Linus Torvalds
2004-10-25 15:43 ` Andrea Arcangeli
2004-10-25 16:10 ` Linus Torvalds
2004-10-25 17:22 ` Andrea Arcangeli
2004-10-25 20:04 ` Jeff Garzik
2004-10-26 2:19 ` Miles Bader
2004-10-25 16:20 ` Larry McVoy
2004-10-25 16:47 ` Andrea Arcangeli
2004-10-25 17:12 ` Larry McVoy
2004-10-25 17:34 ` Andrea Arcangeli
2004-10-25 17:18 ` Linus Torvalds
2004-10-25 17:37 ` Andrea Arcangeli
2004-10-26 0:06 ` Roman Zippel
2004-10-26 0:51 ` Linus Torvalds
2004-10-26 2:21 ` Miles Bader
2004-10-27 2:05 ` Roman Zippel
2004-10-27 3:00 ` Linus Torvalds
2004-10-27 4:18 ` Larry McVoy
2004-10-27 16:45 ` Matthias Urlichs
2004-10-27 18:12 ` Buddy Lucas
2004-10-27 20:56 ` Roman Zippel
2004-10-27 21:20 ` Linus Torvalds
2004-10-28 1:14 ` Roman Zippel
2004-10-28 1:34 ` Linus Torvalds
2004-10-27 21:45 ` Alan Cox
2004-10-31 19:50 ` Pavel Machek
2004-10-28 9:20 ` James Bruce
2004-10-28 11:39 ` Geert Uytterhoeven
2004-10-28 13:53 ` Larry McVoy
2004-10-28 14:06 ` Xavier Bestel
2004-10-28 15:10 ` Larry McVoy
2004-10-28 19:20 ` Alan Cox
2004-10-28 19:25 ` David Schwartz
2004-10-28 19:38 ` Kevin P. Fleming
2004-10-28 19:22 ` Alan Cox
2004-10-28 23:22 ` David Schwartz
2004-10-28 23:59 ` David S. Miller
2004-10-29 0:25 ` David Schwartz
2004-10-29 14:31 ` Scott Lockwood
2004-10-29 14:35 ` Xavier Bestel
2004-10-29 17:02 ` The requested ruling (Was: BK kernel workflow) Scott Lockwood
2004-10-30 2:08 ` David Schwartz
2004-10-28 19:59 ` BK kernel workflow Adrian Bunk
2004-10-28 21:35 ` Larry McVoy
2004-10-30 6:51 ` Adrian Bunk
2004-10-30 23:46 ` Larry McVoy
2004-10-30 23:05 ` Alan Cox
2004-10-31 17:47 ` Larry McVoy
2004-10-31 0:28 ` Robert Love
2004-10-31 1:11 ` Adrian Bunk
2004-10-29 17:19 ` Ramón Rey Vicente
2004-10-29 17:36 ` Larry McVoy
2004-10-29 18:06 ` Stephen Frost
2004-10-29 18:20 ` Larry McVoy
2004-10-29 18:08 ` Ramón Rey Vicente
2004-10-29 18:21 ` Larry McVoy
2004-10-29 18:33 ` Scott Lockwood
2004-10-29 18:55 ` Ramón Rey Vicente
2004-10-29 19:14 ` Scott Lockwood
2004-10-30 5:04 ` Kyle Moffett
2004-10-30 20:42 ` Scott Lockwood
2004-10-30 23:35 ` Larry McVoy
2004-10-31 0:20 ` David Schwartz
2004-10-31 2:37 ` Kyle Moffett
2004-10-31 3:34 ` Larry McVoy
2004-10-31 4:01 ` Kyle Moffett
2004-10-31 4:39 ` Larry McVoy
2004-10-31 2:44 ` Kyle Moffett
2004-10-29 19:39 ` Larry McVoy
2004-10-29 20:33 ` Stephen Frost
2004-10-29 23:38 ` Ramón Rey Vicente
2004-10-29 21:11 ` Adrian Bunk
2004-10-30 2:39 ` Larry McVoy
2004-10-30 2:02 ` Al Viro
2004-10-29 19:13 ` Ramón Rey Vicente
[not found] ` <45898.65.208.227.246.1099077395.squirrel@www.lrsehosting.com>
2004-10-29 19:26 ` Ramón Rey Vicente
2004-10-29 23:01 ` Tim Hockin
2004-10-29 20:32 ` Roman Zippel
2004-10-29 22:41 ` Larry McVoy
2004-10-30 11:38 ` Roman Zippel
2004-10-31 21:03 ` Pavel Machek
2004-10-31 21:14 ` Larry McVoy
2004-10-31 21:21 ` Pavel Machek
2004-10-31 21:35 ` Larry McVoy
2004-10-31 21:46 ` Pavel Machek
2004-10-31 23:44 ` Larry McVoy
2004-11-01 3:16 ` Kyle Moffett
2004-11-01 4:57 ` Larry McVoy
2004-11-01 8:39 ` Pavel Machek
2004-10-26 1:01 ` Larry McVoy
2004-10-27 2:30 ` Roman Zippel
2004-10-27 3:54 ` Larry McVoy
2004-10-27 20:58 ` Roman Zippel
2004-10-27 21:16 ` Joe Perches
2004-10-28 0:54 ` Larry McVoy
2004-10-28 1:49 ` Roman Zippel
2004-10-28 2:35 ` Linus Torvalds
2004-10-28 3:09 ` Larry McVoy
2004-10-28 21:03 ` Roman Zippel
2004-10-28 21:39 ` Eric Mudama
2004-10-28 22:45 ` Larry McVoy
2004-10-28 22:54 ` Roman Zippel
2004-10-29 8:09 ` Manu Abraham
2004-10-29 14:28 ` Scott Lockwood
2004-10-29 15:49 ` Roman Zippel
2004-10-29 16:41 ` David Schwartz
2004-10-29 17:20 ` Valdis.Kletnieks
2004-10-30 0:41 ` David Schwartz
2004-10-29 19:03 ` Chris Friesen
2004-10-29 20:00 ` Ryan Anderson
2004-10-30 0:41 ` David Schwartz
2004-10-31 20:47 ` Pavel Machek
2004-10-31 20:53 ` Larry McVoy
2004-10-31 22:07 ` Sam Ravnborg
2004-10-28 1:05 ` Theodore Ts'o
[not found] ` <mailman.1098759000.989.linux-kernel2news@redhat.com>
2004-10-30 3:55 ` Pete Zaitcev
2004-10-25 19:51 ` Matthias Urlichs
2004-10-26 0:58 ` Andrea Arcangeli
2004-10-26 2:23 ` Miles Bader
2004-10-25 18:18 ` Jon Smirl
2004-10-25 23:01 ` Larry McVoy
2004-10-26 1:28 ` Chris Wedgwood
2004-10-26 2:26 ` Jon Smirl
2004-10-26 6:57 ` Matthias Urlichs
2004-10-26 13:09 ` Giuseppe Bilotta
2004-10-24 17:44 ` Linus Torvalds [this message]
2004-10-24 17:48 ` Linus Torvalds
2004-10-24 18:39 ` Michael Buesch
2004-10-26 7:32 ` Matthias Urlichs
2004-10-24 22:33 ` Roman Zippel
2004-10-24 23:04 ` Linus Torvalds
2004-10-19 23:27 ` Greg KH
2004-10-25 13:01 ` Matthias Urlichs
2004-10-25 14:39 ` Paolo Ciarrocchi
2004-10-25 15:48 ` Jeff Garzik
2004-10-25 16:35 ` Matthias Urlichs
2004-10-25 22:05 ` Andrew Morton
2004-10-20 8:31 ` maximilian attems
2004-10-20 9:05 ` Jeff Garzik
2004-10-26 7:38 Chuck Ebbert
2004-10-26 14:23 ` Larry McVoy
2004-10-26 18:16 ` Ryan Anderson
2004-10-26 19:22 ` Larry McVoy
2004-10-26 15:54 Chuck Ebbert
2004-10-26 20:47 ` Larry McVoy
[not found] <fa.gikv4k0.1tk6shk@ifi.uio.no>
[not found] ` <fa.d7r9f2v.1i6a6on@ifi.uio.no>
2004-10-30 20:54 ` walt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0410241027320.13209@ppc970.osdl.org \
--to=torvalds@osdl.org \
--cc=akpm@osdl.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@bitmover.com \
--cc=lm@work.bitmover.com \
--cc=paolo.ciarrocchi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®