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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
