It was more of an attempt to cutdown on the number of recipients, not
any attempt to keep you out of the discussion. This time, I've left
the recipients alone.
David> Good. You should be prevented from creating a .config which is
David> broken, and the existing CML1 rules attempt to achieve
We are in agreement here, though I doubt that the CML1 ruleset really
achieves this goal in any serious way. It just doesn't have the power.
David> CML2 should continue to do so, and indeed should do so more
David> effectively and flexibly.
David> What I fear is that such new, unwanted, dependencies may be
David> introduced to the kernel -- either by accident or by deception
David> -- in the large patch which introduces CML2 and converts the
David> existing rules files. Subtle changes to the behaviour could
David> easily go unnoticed in such a large patch.
I don't agree with this, since the current CML1 scheme has wierd,
unwanted and wrong dependencies already, which can't (or haven't) been
found. Since it would be put in during the 2.5.x branching, it's
expected that things will/can/should break, so I don't think there
will be any dire consequences.
David> I think you are being overly defensive. I was not saying that
David> CML2 is wrong. I said that I was ambivalent about CML2, and the
David> point I'm talking about is entirely irrelevant to CML2 - except
David> that I'm trying to make sure that the large CML2 patch is not
David> used as a vehicle for sneaking other, more contentious, changes
David> into the kernel.
Such as what? Do you have any examples here?
David> I want to discuss those changes _separately_ once the CML2
David> issue is out of the way, because otherwise people just won't
David> bother to read what I said, and will assume I'm arguing against
David> CML2 itself.
This is the first time you have come out and explicitly *said* what
you are for and against in CML2. People need to be clear about what
they are talking about.
As a general question for all readers, how many are against CML2 in
any shape or form?
How many are like David, and don't mind CML2, but are worried about
How many think CML2 and it's dependencies will be a step forward in
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/