[lkml]   [2005]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: merge status

    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 ;)

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2009-11-18 23:46    [W:0.020 / U:32.344 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site