Re: [Gnu-arch-users] Features command for arch

[David Allouche]

After our discussion on #arch (and some enlightening comments about how
you tend to circle around proposals before making a landing), I think I
understand better where you stand.

As a prolog, I want to point out that "features" is a misleading name.
The intended use is more about bugfixes and updates rather than
divergent functionality.

Tom Lord wrote (in a different order):
> An answer implies/includes, to name a few things, how feature names
> are decided, who/how feature presense/absense is asserted, what valid
> feature names are, etc.

> Next: I like to be frugal with new design add-ons.   If it's *really*
> necessary to add something new, hopefully it should solve lots of (or
> a very general) existing problems.   "Features" seems a bit isolated
> to me, in this context. 

I do not understand what you mean by "isolated".

This proposal aims to solve the tla instance of the general problem of
handling API changes. Existing solutions to similar instances of this
problem are protocol and library versioning.

Maybe the solution can be made more general and future proof, to support
testing for the presence of optional/third-party modules in an
extensible framework, but that is NOT the problem I am trying to
address.

> James' suggestion was something like named boolean flags, set I
> presume in a static array in some C file --- is that about right?

The proposal I have in mind (after discussion with Robert Collins) is
slightly more elaborate.

      * Features are static and describe only the compile-time state of
        tla.
      * The "feature mapping" F maps "feature names" N (strings) to
        "feature versions" V (nonnegative integers).
      * F(N):V+1 implies F(N):V.

This feature mapping F:string->integer can be transformed into a mapping
F:string->boolean. In the unlikely event you have a problem with the
math, please ask.

There are a two reasons why we need fine-grained versioning:

     1. To explicit the mapping between tla releases (what the
        maintainer defines) and the API changes (what the scripts are
        interested into). This helps providing compatibility with
        earlier released versions of tla.
     2. To make it possible to support features as soon as they are
        present in development versions of tla.

The first point has already been elaborated, so I am going to focus on
the second point and the way it relates to the tla development process.

Recent experience has shown that front-end development drives bugfixing
and feature improvements in tla. Here is the basic scenario:

     1. A front-end developer isolates a bug or a missing option
        (something much smaller that what you would ordinarily call a
        "feature") in tla.
     2. He describes the problem to a tla developer (maybe the same
        person with a different hat) who agrees to implement the
        requested change, or informs him he already has this change in
        his tree.
     3. Some functionality can be provided in the absence of the fix,
        but the fix makes it possible to:
             A. provide more value (e.g. more reliability or
                performance)
             B. or use a simpler code path (making it possible to
                isolate and and eventually remove the workaround code).
     4. The front-end developer asks a tla developer (maybe the same
        person) to provide a feature flag. If the developer implementing
        the fix is different from the developer implementing the flag,
        the latter asks the former to merge the new feature flag.

> who controls the namespace of them and how?

Nobody does. And that is going to work because of the community process
and because the nature of the names is different depending on whether
they are used for "past" support or for "experimental" support.

***************************************************************

I'm getting tired of writing this. Probably you are getting tired of
reading this. So I'm going to be sketchy for the rest of the message.

Since the feature name space is going to be managed by the same
community that develop tla, and because name conflicts are self
defeating, there is no need to ensure uniqueness explicitly. Actually,
ensuring uniqueness (e.g. by using the Arch name space) only makes it
safer to bypass the community process.

"Feature names" are slash-separated sequences of xl symbols. By
convention, when they pertain to a specific subcommand, they start by
the name of the subcommand and a slash.

For example "archive-meta-info/fail-when-missing:1" could have been the
name of the archive-meta-info fix.

> For example: revision libraries have parameter settings (e.g., the
> greedy and sparse flags).   Should "features" variables *really* be a
> fundamentally different thing?  or is there usefully some more general
> concept that would make "features" and revision library params the
> same thing?

Library params are configuration settings. "tla features" are compile-
time information. I see them as fundamentally different.

> Such a table is easy to code up an understand, but also easy to make a
> mistake with while maintaining it

I agree with you that it's more difficult to maintain than ordinary code
because it does not _do_ something. But I believe the wider
(distributed) development process will be effective at avoiding
mistakes.

If you are really concerned, you could encourage feature flags to be
accompanied by test cases. Since feature are about observable behaviour
changes, it will always be possible.

It may happen that the test be VERY difficult and then the feature flag
would be very useful, so providing a test case should not be a
requirement. 

-- 
                                                            -- ddaa