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    [from the cache]
©2003-2011 Jasper Spaans