second thoughts about DEPRECATED and OBSOLETE maturity levels

second thoughts about DEPRECATED and OBSOLETE maturity levels

[Robert P. J. Day]

  having championed the cause of adding those two code maturity levels
to init/Kconfig, i just realized that implementing them as simple
dependencies has a *really* annoying shortcoming.

  in order to display that a kernel config feature is experimental,
developers have not only made that feature depend on EXPERIMENTAL, but
they've also had to *explicitly* add the trailer "(EXPERIMENTAL)" to
the prompt line in the Kconfig file, to make it visually obvious.

  obviously, it would be *way* nicer if that trailer were produced on
the fly for any "EXPERIMENTAL" feature, just as it would be for
OBSOLETE or DEPRECATED (or any other maturity levels people can dream
up).

  one solution is to hack Kconfig to look for specific dependencies
that represent maturity levels and add them automatically to those
respective lines.  doable, but kind of hacky.

  another solution is to add a new keyword like "status" or
"maturity", so that:

  config EXT4DEV_FS
        tristate "Ext4dev/ext4 extended fs support development (EXPERIMENTAL)"
        depends on EXPERIMENTAL
	...

becomes simply:

 config EXT4DEV_FS
        tristate "Ext4dev/ext4 extended fs support development"
        maturity EXPERIMENTAL
	...

internally, it could still be treated as a simple dependency, and
everything would still work.

  you know, this seemed so simple at first ...

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: second thoughts about DEPRECATED and OBSOLETE maturity levels

[Sam Ravnborg]

On Sun, Feb 25, 2007 at 05:07:24PM -0500, Robert P. J. Day wrote:
> 
>   having championed the cause of adding those two code maturity levels
> to init/Kconfig, i just realized that implementing them as simple
> dependencies has a *really* annoying shortcoming.
> 
>   in order to display that a kernel config feature is experimental,
> developers have not only made that feature depend on EXPERIMENTAL, but
> they've also had to *explicitly* add the trailer "(EXPERIMENTAL)" to
> the prompt line in the Kconfig file, to make it visually obvious.
> 
>   obviously, it would be *way* nicer if that trailer were produced on
> the fly for any "EXPERIMENTAL" feature, just as it would be for
> OBSOLETE or DEPRECATED (or any other maturity levels people can dream
> up).

I have envisioned that this tag could be added by Kconfig automatically for
all symbols that are dependent on EXPERIMENTAL.
To do so the new option syntax could be extended.
So we had something like:
config EXPERIMENTAL
	bool "Bla bla"
	option adddisplay=(EXPERIMENTAL)

This would cause all symbols selected by EXPERIMENTAL to have
the string "(EXPERIMENTAL)" added to the prompt when displayed.

Same could be used for DEPRECATED and OBSOLETE.

I have not looked into the feasability to implement this - other
Kconfig items needs to be fixed first.

	Sam

Re: second thoughts about DEPRECATED and OBSOLETE maturity levels

[Robert P. J. Day]

On Mon, 26 Feb 2007, Sam Ravnborg wrote:

> On Sun, Feb 25, 2007 at 05:07:24PM -0500, Robert P. J. Day wrote:
> >
> >   having championed the cause of adding those two code maturity levels
> > to init/Kconfig, i just realized that implementing them as simple
> > dependencies has a *really* annoying shortcoming.
> >
> >   in order to display that a kernel config feature is experimental,
> > developers have not only made that feature depend on EXPERIMENTAL, but
> > they've also had to *explicitly* add the trailer "(EXPERIMENTAL)" to
> > the prompt line in the Kconfig file, to make it visually obvious.
> >
> >   obviously, it would be *way* nicer if that trailer were produced on
> > the fly for any "EXPERIMENTAL" feature, just as it would be for
> > OBSOLETE or DEPRECATED (or any other maturity levels people can dream
> > up).
>
> I have envisioned that this tag could be added by Kconfig automatically for
> all symbols that are dependent on EXPERIMENTAL.
> To do so the new option syntax could be extended.
> So we had something like:
> config EXPERIMENTAL
> 	bool "Bla bla"
> 	option adddisplay=(EXPERIMENTAL)
>
> This would cause all symbols selected by EXPERIMENTAL to have
> the string "(EXPERIMENTAL)" added to the prompt when displayed.
>
> Same could be used for DEPRECATED and OBSOLETE.

yup, that makes much more sense than my original idea of just
introducing simple dependencies.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: second thoughts about DEPRECATED and OBSOLETE maturity levels

[Robert P. J. Day]

On Mon, 26 Feb 2007, Sam Ravnborg wrote:

> On Sun, Feb 25, 2007 at 05:07:24PM -0500, Robert P. J. Day wrote:
> >
> >   having championed the cause of adding those two code maturity levels
> > to init/Kconfig, i just realized that implementing them as simple
> > dependencies has a *really* annoying shortcoming.
> >
> >   in order to display that a kernel config feature is experimental,
> > developers have not only made that feature depend on EXPERIMENTAL, but
> > they've also had to *explicitly* add the trailer "(EXPERIMENTAL)" to
> > the prompt line in the Kconfig file, to make it visually obvious.
> >
> >   obviously, it would be *way* nicer if that trailer were produced on
> > the fly for any "EXPERIMENTAL" feature, just as it would be for
> > OBSOLETE or DEPRECATED (or any other maturity levels people can dream
> > up).
>
> I have envisioned that this tag could be added by Kconfig automatically for
> all symbols that are dependent on EXPERIMENTAL.
> To do so the new option syntax could be extended.
> So we had something like:
> config EXPERIMENTAL
> 	bool "Bla bla"
> 	option adddisplay=(EXPERIMENTAL)
>
> This would cause all symbols selected by EXPERIMENTAL to have
> the string "(EXPERIMENTAL)" added to the prompt when displayed.
>
> Same could be used for DEPRECATED and OBSOLETE.

i'll make one more observation on this, then i'll shut the heck up
about it.

i'm wondering if there's any advantage in defining a code maturity
level as something *beyond* just a regular dependency, as you're doing
above.  what you have above will definitely work, but i'm wondering if
there's some benefit to actually defining a new keyword, such as:

config FUBAR
	depends on ....
	maturity EXPERIMENTAL

while the "maturity" level could still be processed *internally* as a
dependency, if you think about it, it's not *really* a dependency,
it's more like an *attribute* or *status* or something like that, and
it may be that there's some value to distinguishing it from a normal
dependency that's not immediately obvious at the moment.

just thinking out loud.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================