[lkml]   [2008]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Slow DOWN, please!!!

    On Thu, 1 May 2008, Willy Tarreau wrote:
    > >
    > > Any suggestions on how to convince people that their code is not worth
    > > merging?
    > I think you're approaching a solution Linus. If developers take a refusal
    > as a punishment, maybe you can use that for trees which have too many
    > unresolved regressions.

    Heh. It's been done. In fact, it's done all the time on a smaller scale.
    It's how I've enforced some cleanliness or process issues ("I won't pull
    that because it's too ugly"). I see similar messages floating around about
    individual patches.

    That said, I don't think it really works that well as "the solution": it
    works as a small part of the bigger picture, but no, we can't see
    punishment as the primary model for encouraging better bevaiour.

    First off, and maybe this is not true, but I don't think it is a very
    healthy way to handle issues in general. I may come off as an opinionated
    bastard in discussions like these, and I am, but when it actually comes to
    maintaining code, really prefer a much softer approach.

    I want to _trust_ people, and I really don't want to be a "you need to do
    'xyz' or else" kind of guy.

    So I'll happily say "I can't merge this, because xyz", where 'xyz' is
    something that is related to the particular code that is actually merged.
    But quite frankly, holding up _unrelated_ fixes, because some other issue
    hasn't been resolved, I really try to not do that.

    So I'll say "I don't want to merge this, because quite frankly, we've had
    enough code for this merge window already, it can wait". That tends to
    happen at the end of the merge window, but it's not a threat, it's just me
    being tired of the worries of inevitable new issues at the end of the

    And I personally feel that this is important to keep people motivated.
    Being too stick-oriented isn't healthy.

    The other reason I don't believe in the "won't merge until you do 'xyz'"
    kind of thing as a main development model is that it traditionally hasn't
    worked. People simply disagree, the vendors will take the code that their
    customers need, the users will get the tree that works for them, and
    saying "I won't merge it" won't help anybody if it's actually useful.

    Finally, the people I work with may not be perfect, but most maintainers
    are pretty much experts within their own area. At some point you have to
    ask yourself: "Could I do better? Would I have the time? Could I find
    somebody else to do better?" and not just in a theoretical way. And if the
    answer is "no", then at that point, what else can you do?

    Yes, we have personalities that clash, and merge problems. And let's face
    it, as kernel developers, we aren't exactly a very "cuddly" group of
    people. People are opinionated and not afraid to speak their mind. But on
    the whole, I think the kernel development community is actually driven a
    lot more by _positive_ things than by the stick of "I won't get merged
    unless I shape up".

    So quite frankly, I'd personally much rather have a process that
    encourages people to have so much _pride_ in what they do that they want
    it to be seen as being really good (and hopefully then that pride means
    that they won't take crap!) than having a chain of fear that trickles

    So this is why, for example, I have so strongly encouraged git maintainers
    to think of their public trees as "releases". Because I think people act
    differently when they *think* of their code as a release than when they
    think of it as a random development tree.

    I do _not_ want to slow down development by setting some kind of "quality
    bar" - but I do believe that we should keep our quality high, not because
    of any hoops we need to jump through, but because we take pride in the
    thing we do.

    [ An example of this: I don't believe code review tends to much help in
    itself, but I *do* believe that the process of doing code review makes
    people more aware of the fact that others are looking at the code they
    produce, and that in turn makes the code often better to start with.

    And I think publicly announced git trees and -mm and linux-next are
    great partly because they end up doing that same thing. I heartily
    encourage submaintainers to always Cc: linux-kernel when they send me a
    "please pull" request - I don't know if anybody else ever really pulls
    that tree, but I do think that it's very healthy to write that message
    and think of it as a publication event. ]


     \ /
      Last update: 2008-05-01 01:23    [W:0.025 / U:5.552 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site