lkml.org 
[lkml]   [2005]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: starting with 2.7
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    My scheme involved a 6 month release cycle supporting kernels with
    bugfixes for the prior 18 months (3 releases), though if you're really
    committed to hardware driver backporting, I guess it can be done in the
    actiwve "Stable" branch.

    I really don't like the idea of driver backporting to maintain a
    supported tree because A) sometimes drivers can't work without invasive
    changes (reiser4); and B) somebody has to do the backporting, which
    means somebody may be facing an assload of extra work.

    The last 6 paragraphs of [1] sketch it out fine; though the whole
    article was pretty much geared towards discussing the Linux Kernel
    development model.

    I just want a development model that makes everyone happy. I don't want
    to load up maintainers with a billion hours of backporting; but I don't
    want to load distributors with excess work either.

    Other interesting variations would be to allow driver backporting for
    uninvasive drivers, via third party support. The maintainer would have
    to merge drivers into the stable kernel; but it would be up to other OSS
    developers (i.e. distributions most likely) to supply those backports.
    This would distribute the work.

    Oh well, what do I know? :)

    [1] http://woct-blog.blogspot.com/2005/01/finally-new-pax.html

    Christoph Hellwig wrote:
    | [wrong cc list last time]
    |
    | On Fri, Jan 07, 2005 at 11:15:08AM +0000, Christoph Hellwig wrote:
    |
    |>On Fri, Jan 07, 2005 at 12:07:33PM +0100, Nicolas Mailhot wrote:
    |>
    |>>Hi all,
    |>>
    |>>Since 2.6 is turning into a continuous release, how about just taking
    |>>the last 2.6 release every six months and backport security fixes to it
    |>>for the next half year ?
    |>
    |>Half a year is far too long because hardware is changing to fast for that.
    |>Three month sounds like a much better idea.
    |>
    |>The real problem is that this is a really time-consuming issue, so
    |>there need to be people actually commited to doing this kind of thing.
    |>
    |>Andres Salomon from the Debian Kernel maintaince team has been thinking
    |>about such a bugfix tree, but he's worried about having the time to
    |>actually get the work done - and we know what we're talking about as
    |>we're trying to keep a properly fixed 2.6.8 tree for Debian sarge.
    |>
    |>-
    |>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/
    |
    | ---end quoted text---
    | -
    | 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/
    |

    - --
    All content of all messages exchanged herein are left in the
    Public Domain, unless otherwise explicitly stated.

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.0 (GNU/Linux)
    Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

    iD8DBQFB3sfMhDd4aOud5P8RAnKIAJ0YatkLwCSP9/69aavUBjI7Rxi9RgCfUfB0
    X2vS+7BKGJyr2O4X3PWmpXM=
    =kbdb
    -----END PGP SIGNATURE-----
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.048 / U:33.456 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site