[Gnu-arch-users] RFC: Logic patch/feature dependecies in arch

[chth]

The following text is available at:
http://wiki.gnuarch.org/moin.cgi/Discuss_20Arch_20features_2fLogicDependcyTracking

I rather like to evolve the idea on the wiki than on the ML.

        Christian



Here the text:

1. RFC - Logic patch/feature dependecies in arch

Work in progress

I will introduce a (still immature) idea for a dependency tracking of
changesets here.

   1. RFC - Logic patch/feature dependecies in arch
         1. Addressed Problems
         2. Goal
               1. Application Examples
         3. Implementation
               1. What gets tracked (aka patch-log headers)
               2. Interface
                     1. tla import|commit
                     2. tla star-merge|replay|update (etc.)
                     3. Other commands
               3. Implementation Details
         4. Final Words

1.1. Addressed Problems

Cherrypicking patches is not enough. Applying a patch successfully does
not mean that the software will run or even build successfully.

If some Project is developed in multiple branches it requires that the
programmers do a lot acknowledgements about which patches depend on each
other and which might conflict. Picking patches based on log reviews is
a cumbersome and error prone task.

Multi tree project configurations are set up by the principal
Maintainer, there is no concept to build a sourcetree in a
user-specified way.

1.2. Goal

Providing a simple and robust interface for tla users to manage
dependencies of changesets by tracking:

    * dependencies
    * conflicts
    * symbolic feature names 

1.2.1. Application Examples

    * Bugfixing out of Sequence

            One implementing some functionality (patch-2,patch-3),
discovers some bug which needs to be fixed before continuing on the main
work (patch-4, patch-5) and then finished the main stuff (patch-6).
Someone who needs only the bugfix would cherrypick patch-5, which
depends on patch-4 and should be applied too. Someone who wants the new
functionality picks patch-6, which should recursively pick all its
dependencies (patch-2 to patch-6). 
    * Microbranching

            If single features are developed in small branches and
merged into a mainline--branch, the merge provides a symbolic feature
name for the functionality. 
    * User Configuration management of Sourcetrees

            Imagine a Linux sourcetree where one can provide a
configuration which defines what part he wants to get/update based on
features. Only arch-x86 and the device drivers he is interested in for
example. 
    * Branched development

            Big projects are sometimes forked and developed by many
Developers/Groups. Merging between such branches can become complicated
because the developers might introduce conflicting features and
communication between such groups is hardly to manage. Dependency
tracking would make merging such projects easy. 

1.3. Implementation

Tracking dependency information by new metadata either in the patch-logs
or in some new metadata container.

Dependencies are based on

    * Absolute Revision Names

            Revision names as usual 

or

    * Symbolic Feature Names

            A Symbolic feature has the form location/name--feature if
location is omited then the location associated with the current source
is choosen. Feature names are archive global (just enough to distinguish
them in the global namespace), rationale behind this is that we
introduce logical dependencies. There is no need to associate them with
actual code (one might add a tests-passed--feature or
gpl-compatible--feature for example). Symbolic feature names are
dynamically bound and updated to revision names and not static aliases
see later. 

      1.3.1. What gets tracked (aka patch-log headers)

      Features:

            Association between known feature names and revisions
address@hidden/something--feature    
address@hidden/foo--bar--1.0--patch-3 

      Provides:

            List of Symbolic Feature names which are provided by this
changeset 

      Inherit Features:

            List of Symbolic Features which will automatically inherited
without that the user have to provide them at every commit (useful for
microbranches or forked development). 

      Depends:

            List of Symbolic Feature names or Revision names on which
this changeset depends. 

      Conflicts:

            List of Symbolic Feature names or Revision names which
conflict with this changeset. Conflicts are automatically inherited and
must be canceled manually. 

      1.3.2. Interface

      Most functionality can be added to tla by some options to few
commands. There are still some unresolved issues like how to handle
multiple arguments of the same kind (--provide foo--feature,bar--feature
or --provide foo-feature --provide bar--feature?). Suggestions are
welcome.

            1.3.2.1. tla import|commit

            Here goes the core functionality in

            --depend REVISION|FEATURE

                  Add a logic dependency on some other revision/feature.
If a FEATURE is given, it must be already known to the tree. 

            --depend-prev

                  Just depend on the previous revision (such a common
case, that it might be worth to add this option) 

            --provide FEATURE

                  Provide FEATURE, FEATURE must already known to the
tree and the Symbolic name is updated to point to this revision. 

            --provide-new

                  Introduce a new FEATURE, FEATURE must not exist. A
Symbolic name which points to this revision is created. 

            there are --provide and --provide-new to safe the user from
adding accidentally new features with a simple typing error.

            --conflict REVISION|FEATURE

                  Mark this changeset to be conflicting with some
revision/feature. If a FEATURE is given, it must be already known. 

            Conflicts are inherited

            --resolve-conflict REVISION|FEATURE

                  Cancel a conflict. 

            --provide-always FEATURE

                  Provide FEATURE and register it as inheriting. Each
successive commit will automatically --provide this feature. 

            --end-provide FEATURE

                  Stop inheriting FEATURE. 

            1.3.2.2. tla star-merge|replay|update (etc.)

            Merges should provide (but not inherit) the features from
the merged revision (this is rather a commit issue too)

            --ignore-dependency REVISION|FEATURE

                  Do not recurse into some dependency (ex: just because
you intend to replace it now). The dependency entry is removed from the
log. 

            --ignore-conflict REVISION|FEATURE

                  Don't stop on some conflict (for the same reason as
above). Remove the conflict from the log. 

            1.3.2.3. Other commands

            Some commands are not mentioned here, but needing attention
later.

            There is certainly some need for some more commands and
integration in other commands for browsing dependencies etc. This RFC
outlined only the most basic required features. 

1.3.3. Implementation Details

      Here i will explain/workout details about the dependency resolving
algorithms later. 

1.4. Final Words

This RFC is quite incomplete and needs to mature a lot. I do not promise
to implement this features anytime soon (but I just would like to use
this features). If we (the arch comminity & Tom Lord) decide to have
such things then we can go further and talk about actual implementation.