lkml.org 
[lkml]   [2002]   [Feb]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: Disgusted with kbuild developers
    Date
    On Friday 15 February 2002 05:04 pm, Eric S. Raymond wrote:

    > Solutions that involve me doing an arbitrary and increasing amount of
    > hand-hacking on every release are right out.

    Um, Eric? Isn't that what being a maintainer basically means?

    Okay, Linus's changes killed backwards compatability with 2.4. (He does
    that. That's what 2.5 is for. It would be nice if less of it happened in
    the stable series, but... :)

    A maintainer is basically there to serve Linus (the project's undisputed
    architect), who periodically makes the architectural decision to break
    backwards compatability on some front.

    You wanted to remain 2.4 help file maintainer as well as 2.5, and Linus did
    not address this concern (for whatever reason: Linus blackholing email as a
    way of disagreeing with it led to a lot of miscommunications like this one.)
    Fine. Water under the bridge. Linus made an architectural decision, and it
    has been implemented. If it means you can't maintain 2.4 anymore, the sane
    move is to drop 2.4 (which you did) and move on.

    That is why this is a dead issue, and bringing it up again doesn't serve as
    much purpose as you think it does. (If you want to highlight the
    blackhole-related miscommunication, fine. But even implying Linus's
    architectural decision was wrong carries no weight with your audience.)

    > If you think this problem through, I'm sure you'll come up with a
    > design very similar to what I actually built. Which, by Linus's
    > choice, got irrecoverably nuked.

    Tough.

    Eric, I like you and I still don't agree with you on this one.

    First of all, the help files really are largely orthogonal to CML2. They
    could be written in gzipped ebcdic. Make a filter, read them, move on. You
    are pointelessly wasting brownie points on a dead side issue.

    Secondly, please define the problem space you're going after. (I think that
    the main objection people have to this tool, they don't agree with the
    definition of the problem you're trying to solve.)

    If you want CML2 is to be the best configure tool for the 2.5 (and later)
    kernel series, fine. Then FOCUS ON THAT PROBLEM.

    Overhead to deal with 2.4 is bloat. Flexibility for projects outside of the
    kernel itself is a side issue. Aunt Tillie is NOT the initial target
    audience. Usage to configure debian userspace or some such is completely
    tangential. All of the above may be fun, but they do not serve to advance
    the primary objective, and bringing them up does not help make a case for
    CML2.

    Back up a bit. What would be the most minimal, stripped-down version of CML2
    you could write? No eye candy, no complications, no autoconfigurator, no
    tree view, no frozen symbols. Just solving the core problem of configuring
    2.5 in a more flexible and less buggy way than CML1, with the three
    interfaces (oldconfig, menuconfig, xconfig) we've got now.

    Think about that for a while. Try to get THAT into the kernel. THEN worry
    about building on top of that.

    Remember: Linus likes small patches. (CONCEPTUALLY small if possible, not
    just lines of code...)

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