[lkml]   [2006]   [Sep]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 2.6.19 -mm merge plans
    On Thu, Sep 21, 2006 at 02:52:08PM -0700, David Miller wrote:

    > But even on that note I would love to have a release cycle where I
    > didn't merge any new features and could work entirely on the bugs
    > that never get worked on.

    Would certainly be nice, even if we didn't do it every-other, but
    once every half dozen or so releases. I've been looking over the
    osdl bugzilla recently (Ironically in a form of escapism from
    the Fedora bugzilla). There's a ton of really old reports in there
    that could be mopped up with a targetted bugfixing release.
    Right now, with so many open bugs, it's difficult to get a real
    picture of where the problem areas are because there's so much
    crap in there. (Fedora's bugzilla is actually going through the
    same problem right now too sadly, at least in part because
    the last few releases have taken so damned long to come out, and
    the -stable releases whilst an improvement, haven't gone far
    enough to fixing a lot of issues users are seeing[*]).

    > Sure, I'll still be merging new features into my "N + 1" tree.
    > But my pure interactions with Linus's tree can focus entirely
    > on bug fixing, and I really want an environment in which to
    > concentrate on that exclusively.

    There's nothing actually stopping you from enforcing this rule
    in the trees you maintain though. You could do this for networking
    in .19 without having a mandate from Linus that the kernel as
    a whole is going to do the same.

    Not that networking is an area that sees that many regressions
    compared to other subsystems IMO. What's your secret? :)

    > I think the even/odd idea is great, personally. And if this
    > makes some people have to wait a little bit longer for their
    > favorite feature to get merged, that's tough. :-)

    My concern is that people will 'sit out' the even stage, and
    just accumulate stuff in a single tree they dump once when
    every odd release opens up.

    We already have some subsystems that do once-per-release merges,
    and then let fixes build up in their out-of-tree SCM for months
    until the next window. It won't necessarily get worse, but unless
    everyone is participating in the odd/even rules, we won't get
    the benefits that it would offer.


    [*] I'm not demeaning Greg & Chris' work here at all, they've
    been doing a stellar job, but I think we could use more people
    going through the changelogs looking for stuff that needs
    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: 2006-09-22 00:11    [W:0.027 / U:5.500 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site