lkml.org 
[lkml]   [2002]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: A modest proposal -- We need a patch penguin
    Date
    On Wednesday 30 January 2002 05:36 pm, Larry McVoy wrote:
    > On Wed, Jan 30, 2002 at 02:17:05PM -0800, Linus Torvalds wrote:
    > > The way BK works now, if we call the quick-and-dirty fix "A", and the
    > > real fix "B", the developer has a really hard time just sending "B" to
    > > me. He'd have to re-clone an earlier BK tree, re-do B in that tree, and
    > > then send me the second version.
    > >
    > > I'm suggesting that he just send me B, and get rid of his tree. There are
    > > no dependencies on A, and I do not want _crap_ in my tree just because A
    > > was a temporary state for him.
    >
    > And you just lost some useful information. The fact that so-and-so did
    > fix A and then did B is actually useful. It tells me that A didn't work
    > and B does. You think it's "crap" and by tossing it dooms all future
    > developers to rethink the A->B transition.

    <rant>

    The noise to signal ratio is too high. I think Linus has made it clear that
    he actively does not WANT this information. (The "A" kind of patch is
    generally posted to linux-kernel, where it is buried deep in the flood.)

    If developers can't ever make temporary changes to their tree which they do
    NOT intend to send to linus, they can't FUNCTION. (Except my not doing
    development in said tree.)

    They can, of course, explicitly do an end run around your "bondage and
    discipline" design by doing the "patch against the base tree" thing you
    suggested earlier. Or just having it create plain diffs. But if they have
    to go to lengths to work around your design to accomplish what THEY want (not
    what you want for them), then the tool is broken.

    > There is a reason that commercial companies guard their revision history
    > and fight like mad to preserve it. It contains useful information,
    > even the bad stuff is useful.

    Do you REALLY think that Linus wants the experimental, quickly-reverted crutf
    of 300 maintainers accumulating in his tree?

    Linux development is not a commercial company. It is FAR more decentralized.
    There are WAY more developers, doing WAY more experimentation, than most
    commercial companies could EVER afford to fund the man-hours for. A
    commercial company generaly doesn't have bored college students futzing
    around with random ideas that have a 95% chance of failure, but occasionally
    produce something brilliant. And a month of experimental baggage tag along
    with a twenty line patch is just insane.

    Trying out way more bad code than good is probably the NORM for the Linux
    development model. Certainly outside of the core maintainers and
    lieutenants. What you're basically saying is that people have to be really
    careful about ever putting any code into their tree, or else just extract
    straight patches from bitkeeper and put up with losing the tracking
    information and comments to avoid having your design ideas cram megabytes of
    cruft down their throat.

    Good grief, -I- can see this is a bad idea...

    > Some stuff may be so bad that it shouldn't ever get in the tree, but you
    > don't accept anything at all from those people in general.

    Not directly, no. So basically, you're trying very hard to prevent bitkeeper
    from spreading far down the maintainer tree, due to the exponentially
    increasing number of overridden patches that bitkeeper will suck out of
    everybody's trees no matter how hard they try to avoid passing that garbage
    on to Linus.

    Remember Linus's main job? Code reviewing everythign and making
    architectural decisions? Why on earth are you trying to force the poor man
    to read code that the submitter does NOT present to him as the solution?
    (There's 8 zillion ways NOT to fix a given problem. We're trying to REDUCE
    the bandwidth demands on the guy...)

    AAAAAAAAAH!

    Okay, I'm better now.

    (Sorry, this is a hot button issue with me. Tool makers who insist they know
    how those tools should be used and what for, and thus reject feedback from
    users asking for greater flexibility with a "no, you don't want to DO that".
    Hammer vendors should not tell me what kind of nails to use.)

    > If Al Viro
    > takes one pass at a problem and it works well enough that it gets in
    > the tree, and then later does a pass two that cleans it up, I can learn
    > from that. That's very useful information, his brain frequently shines
    > a light in a dark corner but I'd miss a lot of that without the history.

    So go read linux-kernel.

    Giving people the OPTION of folding this cruft into the tree is one thing.
    FORCING them to do so is just WRONG.

    > Your approach is constantly dropping useful information on the floor.

    Information which does not belong in Linus's tree. (You're basically saying
    Linus should add a subset of the rejected patch set to his tree's revision
    history. Does it sound like a dumber idea to have Linus put EVERY rejected
    patch he deletes into his tree's history in some automated way?)

    Monolithic evil. Proper tool for proper job, don't try to force the job to
    adapt to what you think the tool is good for.

    > It may not be useful to you but it's useful to virtually everyone
    > else.

    I would like to go on record as saying I don't consider this useful. I don't
    have always enough bandwidth to read through every -pre diff. This stuff
    gets discussed on linux-kernel. People are talking about a patch archive
    system which may save rejected patches for posterity. This is a seperate
    problem, and has a chance of succeeding exactly because it is NOT tangled
    with the issue of source control for the main tree.

    > Saving that information will increase the quality and reduce
    > the quantity of the patches you get.

    Uh, Larry? By definition, adding unnecessary reverted patches for dependency
    purposes to the set of patches Linus would have to apply to his tree is
    increasing the number of patches Linus actually would have to deal with, if
    he was using bitkeeper-to-bitkeeper. You are FORCING people to do everything
    as diff -u and drop MORE information, because YOU are not being flexible here.

    </rant>

    Rob
    -
    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 13:18    [W:2.249 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site