a quick few questions

[Tom Lord]

    > From: Tom Tromey <tromey@redhat.com>

Thanks.

Ok, so some short answers are:

1. The asynchrony of commits to various testers catching up to those
    is a bit smaller than I thought.  It isn't considered a problem.

2. Moderate test suite speed-ups and increases in the granularity at
   which tests can be selected for various kinds of run are possible
   and happen slowly over time.  

   Aegis like commit shields aren't the right semantic the acceptance
   criteria are currently too complex and dynamic to want to maintain
   as code.  This is not a surpise.

Which leaves:

    >>> A variation on this is to continue to allow commits without
    >>> enforced testing, but then have an auto-created branch from
    >>> that that lags by some amount of time but contains only
    >>> revisions that certainly pass certain tests.

    > Or the monotone idea, which is to have the auto-testers tag 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.

Essentially the same thing as what you'd do in arch.  Rather different
"surface syntax".


    > 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.

Thank you for the clear description of the use for this.   I will
follow up on gnu-arch-users (i'll use a subject which is roughly
"round 3 of gcc vs. arch") and forward your use there and explain how
to do it in arch.

    > If the testers run frequently enough, you could even ask for "version
    > with no fails on x86 linux and which bootstraps on ppc linux", though
    > I would suspect that the commit rate is sufficiently great that it
    > would be unusual for two testers to pick the same revision to test.
    > (Though of course one could purposely set up multiple testers in an
    > organization that synchronize in just this way...)

Yes.

Assuming that hw costs are the bottleneck on testing rates it'd be
interesting to guesstimate the cost of increasing testing bandwidth
until it exceeded the commit rate on mainline and a few "typical"
branches.   Saturated testing ("complete" results for every revision
on every interesting branch, even the trivial results) would make the
kinds of navigation you describe pretty interesting to play with.

There's a nice generalization of this .... g-a-u@gnu.

Thanks,
-t