Robert P. J. Day wrote:
> http://fsdev.net/wiki/index.php?title=Maturity_levels
>
> rday
>
A few comments:
- Your argument should include what the benefits of exposing
DEPRECATED and OBSOLETE as machine-parsable tags are.
- "...it's not really experimental but nonetheless claims to be. Bad
craziness all around."
Won't adding more maturity levels increase craziness? All of the
levels except BROKEN are highly subjective. And such tags can and
will become outdated.
- How is the proposed "maturity" keyword to be used? Will
maturity EXPERIMENTAL
replace
config EXPERIMENTAL
or
depends on EXPERIMENTAL
? One of your examples for the usage of the keyword, "maturity
OBSOLETE && BROKEN", indicates it is the latter.
- In case it is the latter, didn't you mean by this example "maturity
OBSOLETE | BROKEN" rather than "maturity OBSOLETE && BROKEN"?
- I sometimes voiced my opinion that the Kconfig language and files
should stick to reflect the mere dependencies, while presentation
should be left to the UIs. The "maturity" directive is basically
a variant of "config" or "depends on" with added presentational
information. Of course everybody is entitled to have a different
opinion and ask for more presentational markup in Kconfig.
- Something /can/ sensibly be DEPRECATED and OBSOLETE at the same
time.
(This also means the correct term is not maturity /levels/, but
maturity attributes or the like.)
--
Stefan Richter
-=====-=-=== -=-- ===--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
