[lkml]   [2007]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: random thoughts on DEPRECATED and OBSOLETE
    Robert P. J. Day wrote:
    > rday

    A few comments:

    - Your argument should include what the benefits of exposing
    DEPRECATED and OBSOLETE as machine-parsable tags are.

    - "'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
    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
    (This also means the correct term is not maturity /levels/, but
    maturity attributes or the like.)
    Stefan Richter
    -=====-=-=== -=-- ===--
    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: 2007-04-28 18:55    [W:0.021 / U:0.108 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site