With the new test harness I am soliciting ideas of how to manage the transition of new feature and bug fix branches from developers/pull requests into master to insure master remains clean and reliable but it doesn't take days or weeks to get new features and bug fixes into master.
I am working with the assumption that with our current hodge-podge of test hardware it would take about 3 hours to run the equivalent of the current nightly builds on a new feature/bug branch (this means many OS, many compiles, many variations of external packages, many variations of configure options (single, double, quad, complex, 64 bit indices). With the purchase of new hardware it may be possible to get it down to 30 minutes. It will be impossible to get the full test suite with many 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. 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). Thanks Barry Let's not waste time with another war over the status of next. The issues are largely the same with or without next. So if you like the next model, think we are keeping it, if you don't like it, think we are getting rid of it. But regardless, next (nor master) cannot be the dumping ground for broken branches as it has been. Also a couple of simple mined automated tests on GitHub or Bitbucket are not good enough to move branches into next/master. We need extensive testing with many compilers/OS that these sites do not support before something moves up to next/master. Neither next nor master is the place to find bug issues, they (95+ % of bug issues) must be dealt with before the branch ever hits next/master.
