[lkml]   [2001]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Background to the argument about CML2 design philosophy
Date said:
> I don't think there is a "less contentious" part. The same people who
> bitched about the engine are now bitching about the changes I'm
> contemplating in the rulesfiles. It seems clear to me that their
> attitude, in general, has little to do with technical specifics of the
> engine or rulesets and everything to do with resistance to change in
> general and fear of losing control and/or hard-won implicit knowledge
> about the old system.

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. said:
> 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
> rulesfiles.

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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.181 / U:0.124 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site