Message-ID: <Pine.LNX.4.61.0705151009400.9570@yvahk01.tjqt.qr>
Date:	Tue, 15 May 2007 10:16:26 +0200 (MEST)
From:	Jan Engelhardt <jengelh@...ux01.gwdg.de>
To:	Satyam Sharma <satyam.sharma@...il.com>
cc:	Tilman Schmidt <tilman@...p.cc>,
	LKML <linux-kernel@...r.kernel.org>,
	Stefan Richter <stefanr@...6.in-berlin.de>
Subject: Re: Linux 2.6.22-rc1


On May 15 2007 08:04, Satyam Sharma wrote:
> On 5/15/07, Jan Engelhardt <jengelh@...ux01.gwdg.de> wrote:
>> that can be switched on or off.
>> It is for those people that start with an arbitrary .config and
>> work their way through menuconfig to disable all the parts they
>> do not want. So, point no. 1:
>> 
>> * Disabling this menu disables all the fluff inside it,
>> without needing to enter the menu and disable each
>> option one by one (as was the case previously)
>
> This kind of promise was really nice, and why I liked Jan's
> menuconfig patches a lot.
>
> But if:
>
> On 5/15/07, Tilman Schmidt <tilman@...p.cc> wrote:
>> Another essential piece of information. I seem to remember other
>> menus which, when disabled, kept the selection status of the
>> options inside and just hid them from view.
>
> is true, then are we really gaining much from these configmenu's?

If you transform a menu with hidden options (which do NOT "depend on"
the menu - they can't even) into a menuconfig (continuing not to
depend on the menuconfig), the presentation fucks up (especially in
ncurses-menuconfig). That is a good hint something should be taken
more seriously.

So, for menus with hidden options I had a number of options how to
go about them:

 - move the hidden options before the menuconfig or after, so
   the presentation does not bork;

 - leave the menu as-is because there's just so many hidden
   options and a menuconfig entry is detrimental

> [unrelated]
> I wish these new constructs were called "configmenu" and
> _not_ "menuconfig". It causes confusion with the "menuconfig"
> master Makefile rule which has nothing to do with these new
> "configmenu"s.
> [/unrelated]

Indeed.

>> Then of course, one can also turn these menuconfig on (apparently!)
>> to be able to descend into them and select some drivers they like.
>> Point no. 2:
>> 
>> * Since Jens Axboe's stance ["default y idiocy"] is to have
>> these menus disabled by default, people should most likely
>> enable them first before they will be able to enter them.
>
> I do agree that anything non-essential (even if it's just a presentation
> menu that doesn't affect builds) must be default n.
>
>> (I would have wanted them to be always 'y' - it does not affect
>> the build, just opens all menus by default)
>
> IMHO, the real problem with "default y" menuconfig's, is that they
> cause unpleasant surprises to those folks that use the text-based
> "make oldconfig". They get confronted with choices that they never
> bothered about (or even knew existed) previously, and have no
> idea how to answer them -- same problem faced by Tilman, when
> he used oldconfig.
>


> I think what happened here is that Jan really only considered the
> "make menuconfig" users with these new constructs (which makes life
> really simple for them), but "oldconfig" users were unfortunately in for
> unpleasant surprises ...

I can't tell, since I'd just say yes if it asks "Ethernet (10 GbE)?" -
either I have such an adapter or I don't.



So what do we need?

 * 'configmenu' option (with 'endconfigmenu') that works the same as
   'menu' and 'endmenu' (so we can have hidden options), but at the
   same time make the ---> and options inside it disappear when it is
   not selected. Currently, no other type seems to satisfy this.


	Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists