----- Mail original -----
> De: "Barry F. Smith" <[email protected]>
> À: "Franck Houssen" <[email protected]>
> Cc: "Barry F. Smith" <[email protected]>, "petsc-dev" <[email protected]>
> Envoyé: Lundi 15 Janvier 2018 15:08:25
> Objet: Re: [petsc-dev] solicitation of ideas for managing transition to
> master under new test harness of new
> feature/bug fix branches.
>
> Franck,
>
> Thanks. Having a way to compute the dependencies of the tests on the
> chances could dramatically reduce the testing time. Thanks for the
> references.
>
Yes, this can reduce testing time on a daily basis if (and only if !) the
workflow also ensures that :
1) a full test replay is run on a regular basis (one per night for instance).
2) a full gcov-instrumented replay is done once a week (sunday for instance)
and can be used as a daily reference during the week.
> Barry
>
>
> >> variants down to a couple minutes.
> >>
> >> There are issues with race conditions if multiple people want to test and
> >> then move branches over at the same time.
Pre-integration levels (or branches) could also help to avoid most problems of
this kind.
I believe the following sketch will illustrate the idea better than words:
master
| |
preint-ksp preint-snes
| | | |
dev1 dev2 devA devB
If dev1 and dev2 are in a race condition or conflict situations, you'll know it
in preint-ksp (where it's stuck until the validation is OK, and, must be fixed
in priority) without bothering other guys (snes team/dev). In preint, the idea
is to run a full test validation, but, you can also decide to begin the full
replay with TIA tests (most relevant first), or, to run only TIA tests.
Don't know your workflow: maybe you already have this kind of features
integrated to it (?).
I experienced that kind of preint workflow: this is a strict process but very
efficient in the end (most - not all - problems can be avoided as they are
fixed as they show up).
> >> I'm looking for any ideas on how
> >> to limit/eliminate them. We can't have the current situation where
> >> multiple
> >> people put broken things into next and it is difficult to figure out what
> >> branches caused the failures in next and get them fixed promptly, thus
> >> resulting in a sluggish next (and hence sluggish PETSc development).
> >>
