On Sun, 11 Mar 2007, Avi Kivity wrote:
>
> Actually there's at least one tree where this should be activated -- yours.
> If you perform a fast-forward merge, there's no record of the merge, no record
> of which tree was pulled, and no sign-off from you. The commits just appear
> there. It partially defeats the sign-off system.
Well, the thing is, I explicitly don't *want* the merges to show up if
it's a fast-forward.
Maybe it's just me, and maybe I'm odd, but I have for several years now
really thought of Linux development as being this collection of
maintainers, rather than being a "Linus at the top" kind of situation.
So yes, obviously I do end up getting a lot of merges attributed to me,
simply because *in practice* my tree is generally the top of the food
chain, but I think that's a practical issue because people generally want
to avoid confusion by having a known maintainer, and it shouldn't be a
design thing.
So I dislike the "hierarchical model" so much that even though it's true,
I don't want to make it even _more_ true. I'd rather make it less true,
and at least personally think of Linux development more as a "network of
developers where some people are just more connected than others". I'm not
saying that people are equal (because they aren't), but at the same time I
do think that it should be perfectly fine if submaintainers pull from each
other if they ever need to - ie pulling should work side-ways and not just
up the "command chain".
So I think the hierarchical thing is largely a social thing, but not one
that is necessarily the only way of doing things.
And I believe that it might actually be *better* if we were to have some
more merging side-ways. Yes, I've been rather involved in kernel
development for fifteen years, and I don't really see myself stopping it
either, but at the same time, I think that in the really long run, it
would be a really interesting experiment to try to run things as a more
"amorphous" development group of people that just trust each other, than a
very hierarchical one.
And I really think tools matter, and that it's a much more healthy
environment if you *don't* have the situation where people mark their
merges in a hierarchy. If you have people pulling from each other, rather
than a "central repo" model, it really *is* wrong to say "Merge feature
Xyz", because when you then later pull the other way, now that merge
message makes no sense any more.
> This feature would be good for top-level trees and for major subsystem trees
> IMO.
I realize that it can be useful, and I obviously use the "merge.summary"
config variable that does make it a non-symmetric situation anyway, and
maybe I'm just fighting windmills. It's just that I actually dislike the
central repository model so much that I dislike it even when the central
repository is *me*.
The Linux kernel is actually a bit strange in this way. I've always
encouraged people to have their own repositories, in ways that most other
projects do not. So I'm really happy with things like distributions
maintaining their own versions, and with developers having their own
trees, and keeping me honest that way. The -mm tree, the -aa tree, the -ck
tree etc.
I think it's a sign o fa healthy community when there is competition in
the maintainer space. Now, people don't always agree with how I do things,
and yeah, every few years there is some flame war about how I suck ("Linus
doesn't scale" kind of thing), but I think that to keep me reasonably
honest, people always need to have alternatives.
So when I really screw up, or become just _too_ impolite and offend too
many people, I hope that there will be some other person maintaining his
own tree, and people will just flock to that one instead. That's how
things *should* work. And that's why I don't want to have too strict a
hierarchy, or the tools being geared towards a central model.
So I realize that in practice, when things work reasonably well, you
*will* have a central repository. At the same time, I want the tools and
the infrastructure to support the case when somebody says "Linus does a
horrible job, and I can do better".
So I'll fight tooth and nail to show that I'm better and smarter than any
other kernel maintainer, of course, but I'll do that because I *like* the
competition, not because I make the tools favor me, thank you very much.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html