[Gnu-arch-users] [ISSUE] (Round 3), GCC, pqm generalization

[Tom Lord]

Interesting data from the GCC list.   Tom Tromey graciously answered
some quick questions I had about their testing tools but also, in 
that context, gave me some good ideas.  That led to a train of
thought.

Before I get to GCC....

Shields (i.e., commit criteria for a branch) and pqms are both
subspecies of the same general thing.   The general thing
is a deterministic (I'll relax that later) rule defining one
set of output branches in terms of a set of input branches plus datums
from external sources (such as test results).

Let's call that general form of rule, the kind that defines a set of
"implied branches", a "derived branch" (or "derived version" when the
branch/version distinction matters).

An interesting property of an implied branch is that anyone can create
a copy of one given only the antecedent branches and external data,
plus the rule.   All instances (since the rule is deterministic) are
isomorphic to one another.

In some sense, the list of antecedents plus the rule is a good name
for the set of all output branches formed by the rule.

Tom (Tromey's) example of a use case for implied branches comes from
GCC:

    > Or the monotone idea, which is to have the auto-testers [label]
    > revisions as "known good" according to criteria they determine.
    > It is useful to have multiple levels of goodness, eg "bootstrap
    > on x86", "bootstrap on <exotic platform>", "no C regressions on
    > x86-x-mips", "no java regressions", etc, so that users can pick
    > for themselves what they want to check out.

    > For instance, libgcj hackers ordinarily want to check out something
    > that is "pretty good" -- can bootstrap -- but they may not care
    > whether there has been some random mauve regression.  Occasional
    > hackers might want something similar.  Regular core gcc hackers may
    > prefer to be closer to the bleeding edge.

Instead of checking out directly from mainline, the ideal for libgjc
hackers is to check out from an implied branch whose antecedents and
rule is something like "tags from mainline of those revisions which
are buildable".

Someone working on another part of GCC, not libgcj, would also want
the latest revision on some branch -- but their rule might be
different.  For regular core gcc hackers, the rule is probably not far
removed from the "null rule": just get the latest mainline revision.

Implementing Tom's scenario in arch, with no new features, using a
PQM, is fairly trivial.   I would do it by tagging every revision in
mainline with test results for that revision (if computed) and the
nearest ancestors with passes for each failed test.   The kinds of
checkouts he wants can then be performed by reading the latest tag log
message from every tester of interest and finding the latest ancestor 
on mainline that satisfies the user's criteria.

But that's a special case solution and I'm wondering whether the more
abstract view of "implied branches" suggests how pqm should be
generalized and what the interface should look like.

Should it not be possible to send rules and antecedent lists to a pqm
and have it either simply remember those, or both remember those and
eagerly create some implied branches?    Other pqm control messages
could turn on and off which implied branches are eagerly created.
Because (so far), the branches are deterministic,  pqm could keep a
cache of them -- deleting ones not currently demanded.

That works perfectly for deterministic rules.  I think it works just
as well for rules that aren't deterministic, but which for practical
purposes, produces interchangable results given equal inputs.

So, I am beginnnig to conclude that:

1) PQM should be generalized to permit a wide range of rules
   to be dynamically defined.   A simple black-box hook isn't
   right.   PQM needs a standardized language for rules.

2) Rules should have global names and, thus, ought to be stored
   as arch revisions in someplace that the PQM knows about.
   (This includes global names for "abstract rule + explicitly 
   listed antecedents")

3) All antecedents should be checked into arch, not just antecedent
   branches.   For example, raw data from a tester.   That way,
   every revision on an implied branch is uniquely identified 
   with a coordinate:

        rule-revision antecedent-0-revision antecedent-1-revision
          ...


4) The full specification of an implied branch should also have a
   global arch name.  This name is for the UI to that implied branch.

   That way, a user can refer to an implied branch revision with
   a ordered pair:

        (  rule+antecedent-defining-revision

         . selector-of-which-output-revision-from-the-rule )


More succinctly, and in more conventional terms:

The PQM should be extensible in how it creates its output branches.

Moreover, it should be _dynamically_ extensible.  It should allow
people to send it messages pointing out new rules for making implied
branches, or retracting old ones.  PQM should load these rules and
follow them.    Users shouldn't necessarilly care about the literal
names of the output branches of a particular run of the PQM for a
given rule --- sometimes they should be able to query an archive for
whichever implied branches it contains that were created by a
particular rule.


-t