[lkml]   [2005]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFD: Kernel release numbering
    Linus Torvalds wrote:
    > 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.

    The only problem I see with this -- and its a minor problem -- is that
    some patches that belong in the 2.6.X.Y tree go straight to you/Andrew,
    rather than to $sucker.

    It's perfectly workable from a BK standpoint to do

    -> linux-2.6 commit
    -> cpcset into linux-2.6.X.Y [see Documentation/BK-usage/cpcset]
    -> pull from linux-2.6.X.Y into linux-2.6 [dups cset, but no
    real code change]

    but that causes dups in the BK changelog and history. Not a big deal,
    though, just a minor technical nit.


    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: 2005-03-22 14:10    [W:0.023 / U:10.488 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site