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

[David Allouche]

On Mon, 2004-08-30 at 12:09 -0700, Tom Lord wrote:
> That is a wonderful explanation and it alone answers all the immediate
> questions I can think of about the proposal.

Thanks, you almost made me blush :-s

> You could also get by just by looking at the version number of the
> particular tla binary.

That does not scale. There are more "versions" of tla running around
than the released ones. The tla is from some personal branch, it may
have more or less "features" than the official release it is based on.
This problem is especially apparent with new or experimental features
which have not made their way into a release.

Generally, it is considered bad practise to infer features from the
version number.

> On the other hand, jblack's form of the proposal is just for some
> binary flags that you can test and that the tla version you compile
> can set.   That's less structured but is also simpler.
> 
> How can we figure out a good answer to the question of what a
> "feature" is?

In the general case, I do not think we can answer this question without
human judgement. A good rule of thumb would be, as jblack put it:

    Any sort of behavioral change to tla that needs to be accounted for
    in front ends

A more jargonic way of putting it would be:

    Any sort of interface (or contract) change.

That is not exclusive of internal bugfixes and performance improvement,
since a given tool may have implemented workarounds. However, that is
stretching the definition of contract, so internal bugfixes and
performance improvements should not feature-flagged unless there is a
known need.

Example of changes not qualifying as features by default: tagline
detection problem currently being fixed, sftp pipelining, fd leak fixes.

Example of changes qualifying as features by default: archive-meta-info
fix. File name escaping. Inode-sig changes (a front end tool may warn
the user and delete the revision library when an incompatible change is
detetected). Backbuilder (different revlib pruning strategies should be
used).

> Is it really just a binary flag?

The requirements can be met by simple binary flags.

> Does it relate to the arch namespace?
[earlier in your message]
> For example: your particular need could be answered with pretty good
> precision if it were known that certain patches were or were not
> applied to the sources which produced the binary you are running.

That would not cover the case of a feature included then disabled. A
feature can be disabled by the "replay --reverse ; sync-tree" idiom or
by the application of an unrelated (history-wise) patch.

That would also be broken by patchlog pruning.

> Can features be "ordered" in the way that version numbers are?

I did not see the need for that at first, but that was something
suggested by Robert Collins. Robert?

In any case, versioned features do not hurt and can useful in
controlling the growth of the feature flags count. The basic idea is
that "foo:2" is shorthand for "foo:1" AND "foo:2".

> Who can assert, who can test, and who can
> retract the assertion that a feature is present?

I am not sure I understand what you mean here.

assert/retract: through the usual development process. Tla maintainers
would be expected to require (or provide) feature flags when relevant
according to their best judgement. If client code maintainers see the
need for an additional feature flag, they can go through the usual
complain-implement-submit process.

test: any script using tla.

Features describe compile-time characteristic of tla.

>    Must the presense
> of features always be explicitly asserted or can it be inferred in
> some cases?

The point of "tla features" is to provide an obvious and cheap test
allowing runtime configuration for all tla-based tools.

     1. Since features are contract changes, they can always be
        inferred. But most of them (e.g. archive-meta-info-tells-empty)
        require expensive tests.
     2. Some features may be easily inferred, for example file-name-
        escaping is only present if "tla escape -h" does exit(0). That
        is a cheap test, but it falls short of the obviousness
        requirement.

So, features should always be explicitely asserted, when relevant.

The baseline for features would be stable release prior to the inclusion
of "tla features". 

>    Are the best answers to these questions likely to vary
> over time?

I do not feel qualified to answer that question authoritatively, my
crystal ball is currently at the repair shop. :-)

Probably not.

> On the basis of all of the answers:  what is our best
> guess about what actual hacking work to do on this feature?

Initial work: trivial for someone familiar with tla source and coding
practises. Just defining a framework.

Maintenance: small cost over the lifetime of tla to add new feature
flags.

-- 
                                                            -- ddaa