[petsc-dev] does next model mess up our histories

[Dmitry Karpeyev]

The first thing we would have to do to improve the test system is provide
for an automatic  detection of test failure without too many false
positives. The current diff-based setup is not adequate.

MOOSE, for example, uses exodiff to compare the output of the tests to a
"gold standard" in the Exodus II format.
This allows them to tolerate inconsequential mesh renumberings and
floating point errors (discrepancies) to a given tolerance. We currently
depend on matching convergence histories.

Note also that pull requests (at least on GitHub) will be automatically
updated - and trigger a fresh continuous integration test event - when new
commits are pushed to the branch being merged.

I think the automatic test can, in principle, make a temp copy of next,
merge the feature branch into 'next-tmp', and discard the result at the end
of the test. That way 'next' isn't polluted with failed PR attempts. Not
clear how to adapt this to nighlies and multiple outstanding PRs, though.
Merge all the  outstanding PRs into a fresh 'next-nightly' every night?

D.
Satish Balay <balay at mcs.anl.gov> writes:
> I guess another alternative for these veryfew feature branches
> that need to iterate over nightlytest suites is:
>
> - never merge feature branch to next untile its complete
> - switch master or next nightlytest to feature branch [for a few days]
> - fix rebase feature branch as needed.

If we had a continuous integration system, the mere act of creating a
pull request could spawn the builds on many architectures and give us
the results.  MOOSE does this with moosebuild and a zillion project do
it with Travis-CI, Jenkins, etc.

It would be useful, but requires test system improvements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20141002/f3051b7e/attachment.html>