No. I didn't bitch (much) about CML2 - I'm fairly ambivalent. But I
absolutely object to _unconditionally_ dumbing down the config options,
because it would hide options which I would frequently want to enable.
Introduce new novice modes if you wish - that seems sensible - but do not
reduce the functionality and flexibility of configuration which is currently
available. Any simplifications you make _must_ be dependent on the novice
mode, and the default mode should allow the same choices as the current
More importantly, do not attempt to force through this change in policy by
sneaking it into the 2.5.1 CML2 patch which introduces the new mechanism.
The two are entirely orthogonal, and should remain separate.
> I'm going to give Linus the same installation kit the people working
> with CML2 have now. That will include both the CML2 engine and the
Fine. What I'm asking is that you ensure that the CML2 rulesfiles at the
time of the merge implement the dependencies present in the CML1 rulesfiles
immediately prior to the merge.
If you want to work on the change of policy right now, before CML2 is
merged, then go ahead and do it in CML1. It's not difficult. The first step
is to make CONFIG_*_ADVANCED depend on CONFIG_EXPERT, for example. Then get
those changes merged into 2.5 before you merge CML2 - and you still keep the
CML2 after the merge equivalent to the CML1 immediately before the merge.
Otherwise, have patience and do it after CML2 is merged.
All I'm asking is that you refrain from confusing the change in mechanism
with the change in policy. That's not an unreasonable request, now is it?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/