[petsc-dev] solicitation of ideas for managing transition to master under new test harness of new feature/bug fix branches.

[Franck Houssen]

----- Mail original -----
> De: "Barry F. Smith" <bsmith at mcs.anl.gov>
> À: "Franck Houssen" <franck.houssen at inria.fr>
> Cc: "Barry F. Smith" <bsmith at mcs.anl.gov>, "petsc-dev" <petsc-dev at mcs.anl.gov>
> 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).
> >>