gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Andrew Suffield
Subject: Re: [Gnu-arch-users] [ISSUE] (Round 3), GCC, pqm generalization
Date: Thu, 24 Jun 2004 05:28:36 +0100
User-agent: Mutt/1.5.6+20040523i

On Wed, Jun 23, 2004 at 07:50:26PM -0700, Tom Lord wrote:
> 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.

As an aside, there are several data sets involved in tests:

 - the project under test
 - the test suite

    These are two entirely independent projects, with essentially
    free-form branching. For each pair taking one revision from each
    set, you have:

 - a list of tests that passed and failed

    This should be deterministic for the revision pair, but isn't; you
    have to throw target variance into the mix. So it's "mostly
    static", which is decidedly unhelpful. There does exist a single
    "right" value, but the test results you actually get can be
    *inaccurate*, and be refined later.

 - a list of tests that must pass

    This forms the release criteria. For gcc, it's the list of tests
    which have passed in previous releases (note how I just
    demonstrated this isn't well-defined) plus some arbitrary
    choices. This is free-form again (stash it in a third branch).

And we have to deal with some cross-section over all four. (Right now,
I'm focussing on tools to compute and combine these).

Such a branch would presumably be defined in terms of some specific
set of values; the not-so-static nature of test results is annoying
here. I'm still trying to decide what best to do about that. Might
have to go for the "bloody huge database" option.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]