On Thu, 3 Mar 2005, Jeff Garzik wrote:
>
> Greg KH wrote:
> > Sure they've been asking for it, but I think they really don't know what
> > it entails. Look at all of the "non-stable" type patches in the -ac and
> > as tree. There's a lot of stuff in there. It's a slippery slope down
> > when trying to say, "I'm only going to accept bug fixes."
>
> We have all these problems precisely because _nobody_ is saying "I'm
> only going to accept bug fixes". We _need_ some amount of release
> engineering. Right now we basically have none.
I agree that this is one of the main problems.
But look at how to solve it. The _logical_ solution is to have a third
line of defense: we have the -mm trees (wild and wacky patches), and we
have my tree (hopefully not wacky any more), and it would be good to have
a third level tree (which I'm just not interested in, because that one
doesn't do any development any more) which only takes the "so totally not
wild that it's really boring" patches.
In fact, if somebody maintained that kind of tree, especially in BK, it
would be trivial for me to just pull from it every once in a while (like
ever _day_ if necessary). But for that to work, then that tree would have
to be about so _obviously_ not wild patches that it's a no-brainer.
So what's the problem with this approach? It would seem to make everybody
happy: it would reduce my load, it would give people the alternate "2.6.x
base kernel plus fixes only" parallell track, and it would _not_ have the
testability issue (because I think a lot of people would be happy to test
that tree, and if it was always based on the last 2.6.x release, there
would be no issues.
Anybody?
I'll tell you what the problem is: I don't think you'll find anybody to do
the parallell "only trivial patches" tree. They'll go crazy in a couple of
weeks. Why? Because it's a _damn_ hard problem. Where do you draw the
line? What's an acceptable patch? And if you get it wrong, people will
complain _very_ loudly, since by now you've "promised" them a kernel that
is better than the mainline. In other words: there's almost zero glory,
there are no interesting problems, and there will absolutely be people who
claim that you're a dick-head and worse, probably on a weekly basis.
That said, I think in theory it's a great idea. It might even be
technically feasible if there was some hard technical criteria for each
patch that gets accepted, so that you don't have the burn-out problem.
So let's loook at how we could set that up. We need:
- a sucker who wants to do this, or a company that pays for somebody good
to do this (and remember: "good" here doesn't necessarily have to mean
technical genius, it's about taking abuse and being stable). The whole
setup should be such that there can never be any question about the
patches for _other_ reasons (to avoid the sucker becoming a target for
abuse), so this person really to some degree would be fairly
mechanical.
Don't make it automated, though. That just gets us down the path of
flaming about the scripts and automation. And I'm not claiming that we
should aim for somebody _stupid_, I'm just claiming that it takes a
certain kind of person to do something that is not all that glamorous,
and that puts you in the spot.
We don't ever want to have that spark of "wouldn't this be cool" in
this project.
- some very _technical_ and objective rules on patches. And they should
limit the patches severely, so that people can never blame the sucker
who does the job. For example, I would suggest that "size" be one hard
technical rule. If the patch is more than 100 lines (with context) in
size, it's not trivial any more. Really. Two big screenfuls (or four,
for people who still use the ISO-ANSI standard 80x24 vt100)
Also, I'd suggest that a _hard_ rule (ie nobody can override it) would
also be that the problem causes an oops, a hang, or a real security
problem that somebody can come up with an exploit for (ie no "there
could be a two-instruction race" crap. Only "there is a race, and
here's how you exploit it"). The exploit wouldn't need to be full code
that gets root, but an explanation of it, at least.
- a vetting process. You'd have ten people, and five of them would have
to sign off on the patch, and even a single veto would shoot it down.
Again, this is really to protect the sucker, and make it possible to
work: I don't think this can work with a creative person (everybody
else calls me "flaky", and I much prefer that "creative" word, it sounds
so much better), which I personally believe means that we don't _want_
people like Alan, Andrea, Andrew etc etc that have historically maintained
their own trees that sometimes have tried to do something like this.
- Finally: this tree never has any history past the "last release". When
a new kernel comes, the tree is frozen, and never to be touched again.
If somebody _else_ wants to base things off this special "sucker tree",
and make a fourth level tree that is based on the _previous_ stable
tree, that's fine, but that's a separate process. He would be totally
free to do so, but the rule is that this particular maintenance program
_never_ gets stuck on an old kernel, like the vendor trees always are.
This is not a long-range tree, it would _purely_ be about one thing and
one thing only: the last stable kernel. The people involved (sucker and
vetters all) would never have to remember two different trees, or care
about problems that aren't in the top-of-tree. Keep ti simple, and keep
the rules clear.
Does this mean that some patches would never go into this tree? Yes. It
would mean that patches that some people might feel very _strongly_ are
good patches would never ever show up in this tree, but on the other hand,
I can see this tree being useful regardless, and I think the lack of
flexibility in this case is actually the whole _point_ of the tree. The
lack of flexibility is the very thing that makes this be the kind of base
that anybody else can then hang their own patches on top of. There should
never be a situation where "I'd like that tree, but I think xxxx was done
wrong".
Might something like this make people happier? (I wrote "happy" rather
than "happier" at first, but let's face it, people are better at whining
than they are at being happy ;)
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
