[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, 21 Sep 2006, Andrew Morton wrote:
    > Again, before we can implement anything we should describe what problem we are
    > actually trying to solve here.
    > Jeff: "I want faster release cycles because <no reason given>"
    > Me: "I want less bugs"
    > Anyone else?

    Me: "I want peoples expectations to line up".

    (That, btw, is totally independent of this particulay issue - I just like
    people to know what to expect..)

    One of the things that I think the current model has excelled at is how it
    really changed peoples behaviour, simply because they knew and understood
    the rules.

    I think the "big merges in the first two weeks, and a -rc1 after, and no
    new code after that" rule has been working because it brought everybody in
    on the same page.

    I actually expected people to dislike arbitrary rules more than they do,
    but I've come to believe that people _like_ having rules that they have to
    obey, as long as it's not a big pain for them. In other words, arbitrary
    rules are not actually disliked at all, people actually _like_ them,
    because suddenly there's less need for making unnecessary judgement

    As an example: I thought I'd get a lot of back-lash on the whole sign-off
    procedure. Instead, we're basically signing off everything, and having a
    few simple rules ended up making it just easier to forward stuff, and we
    haven't had any of the discussions about who gets to be attributed as an
    author since the sign-off was introduced. That was a totally unexpected
    bonus, as far as I was concerned.

    The same goes for my anal efforts at trying to make people use a specific
    format for sending patches, and sending the "please pull" messages. I'm
    not hearing any grumbling about it at all, and in fact I'm getting the
    distinct feeling that people like knowing exactly what format to use,
    because they didn't really care themselves, and it turns out that having
    any rule - even if it's fairly arbitrary - seems to be better than not
    having a rule at all.

    So I think that a "odd release"/"even release" rule that clarifies what a
    certain mid-point in the release cycle actually _means_, even if it
    doesn't necessarily add anything else, might be a good thing. It just
    solidifies peoples expectations about where we are in a release cycle.

    If we make an arbitrary rule to go with the release cycle ("leading up to
    the even cycle, you need to get an ack from somebody that actually tested
    the fix") that could actually be a good thing, for this reason.

    I dunno. Maybe the only arbitrary rule ends up being that an "odd release"
    would become a good place for people to try, knowing that we expect bug
    reports from them. Right now -rc1 might be _too_ scary, even if it ends up
    being exactly that: the only difference is really not about technology,
    but about what peoples expectations are.

    If we could instill a culture of "if you aren't a developer, but you just
    want to help out, try the odd releases", that in itself might be worth the
    naming change. If it would allow a group of people who might not feel
    comfortable about reporting problems with a "-rc" to feel like they are
    _expected_ to report a problem with an odd release, then that would be a
    good thing, no?

    I'm just throwing this out as an idea. I'm not going to really argue very
    strongly for it. It might have horrible downsides too, for all I know, and
    we might get people who didn't get the memo on "even vs odd releases"
    being really unhappy about somethign they perceive to be a buggy release.

    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.027 / U:33.816 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site