Re: random thoughts on DEPRECATED and OBSOLETE

[Stefan Richter <stefanr@s5r6.in-berlin.de>]

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/