Re: merge status

[Linus Torvalds <torvalds@osdl.org>]

On Wed, 9 Nov 2005, Andrew Morton wrote:
> 
> One could just say "if I don't have it by the time 2.6.n is released, it
> goes into 2.6.n+2", but that's probably getting outside the realm of
> practicality.

I think it would be a good thing to _aim_ for, and just to keep things 
practical just not make it too much of a hard rule.

I think one reason -mm has worked so damn well (apart from you being "The 
Calmest Man on Earth"(tm)) is because it's essentially been that buffer 
for anything non-trivial. Sometimes the "n+2" has been a lot more than 
"n+2" in fact, and that's often good.

(And at the same time, -mm has enough visibility that it doesn't drive 
developers crazy even when the "n+2" ends up being "n+5" or somethiing).

I'd _hope_ that the same kind of situation could work for some of the 
majos subsystem git trees too: where the maintainer tree is well enough 
known that it gets sufficient coverage for that area that a "+2" approach 
for merging into the default kernel is practical.

I also think it certainly _should_ be possible for the big areas that have
well-defined target audiences. Especially since git should hopefulyl be 
very good at allowing such a target audience to actually track (and merge) 
such trees on their own.

Ie it should be perfectly possible (and easy) to track both my tree and 
some other tree (sound, scsi, network device development) in two branches, 
and the person doing that tracking should have basically trivial merging.

So we do have the technology. Whether we can make it work in practice, 
that's another issue ;)

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/