[petsc-users] Release canditate?

[Satish Balay]

On Mon, 14 Dec 2015, Eric Chamberland wrote:

> Le 2015-12-14 11:09, Jed Brown a écrit :
> > Eric Chamberland <Eric.Chamberland at giref.ulaval.ca> writes:
> > > I see.  In fact, I was thinking of 3.6.4.rc1, 3.6.4.rc2, then 3.6.4,
> > > followed by 3.6.5.rc1, 3.6.5.rc2, then 3.6.5, etc...
> >
> > Those patch releases are only bug fixes, not new features.  I'm not
> > aware of PETSc having a problem of introducing bugs in these patch
> > releases and I think vanishingly few users have the patience or interest
> > in testing them.  I recommend using 'maint' (via Git or tarball) if you
> > want the latest bug fixes.
> >
> > > I think I might script something here to wget the tarball, compile it
> > > and run tests automatically with the petsc-master.tar.gz...  so as soon
> > > as some problem appears with our usage or the forthcoming petsc, we will
> > > be able to give feedback...  maybe I could wget it only if your nightly
> > > tests are ok?  Hmmm, maybe your nightly tests could update a symlink or
> > > something "friendly" to wget only if all tests are ok?  For example, if
> > > all tests are sufficiently ok, maybe you could update something like a
> > > "latest-good-petsc-master.tar.gz" which I could wget unconditionally?
> > > Just an idea...
> >
> > It is a technical challenge to have a proof positive "everything is
> > okay".
> >
> 
> I know, but you have all the ingredients: tests and nightly builds with a
> summary.
> 
> You would be able to state a "everything is ok" on that basis.

Yeah Barry has been pushing to get to that stage - [its improved
considerable over the past few months] but not everything is automated
yet.  Its still a manual process to go through the remaining logs and
decide 'ok'/'not-ok'

Satish


>  Then, you will
> always want to have a better code coverage so the "everything is ok" will be
> stronger...  Btw, I saw your code coverage is very good: about 83% !
> 
> Fwiw, we do this here with home made scripts and we automatically deliver new
> versions when our test base is "all green" over 13 different builds (including
> a valgrind one, btw).
> 
> Other funny thing we do: when the code is 100% green, we tag it.  We keep the
> history of "100% green" tags for latter use (finding a regression).  Also,
> some users like to be "on the edge" with all latest features, but only if they
> are working: so they "pull" the new commits and merge/rebase only with "100%
> green" tags... for which we created a git aliase which would be equivalent to
> "git pulltogreen".
> 
> Thanks,
> 
> Eric
> 
> 
>