Matthew Knepley <knep...@gmail.com> writes: > On Sat, Nov 11, 2017 at 1:15 PM, Satish Balay <ba...@mcs.anl.gov> wrote: > >> On Sat, 11 Nov 2017, Matthew Knepley wrote: >> >> > > >> > > BTW: Ultimlately if you want to improve current next model - everyone >> > > has to do a 'make alltests DIFF=$PETSC_DIR/bin/petscdiff' for atleast >> > > one build that has relavent feature options enabled - before merging >> > > the feature branch to next. >> > > >> >> > This does not agree with my experience (I think) for bug finding. It >> > tends to be other architectures (complex, 64-bit int, fortran) that >> > fail for me, which means running that for many builds, and my laptop >> > is just not capable, and furthermore that is why we have a farm of >> > machines. >> >> Your laptop is just an excuse. You can do it on cg.mcs or other >> machines. Infact you can run one of the complex or 64-bit tests >> manually on cg. >> > > And that makes my point. The time for me to login to cg, set > everything up, and run the tests should be automated, and in fact we > already did that for next, which is what should be used.
Merging is synchronous. If I do git checkout master git pull git merge jed/risky-business make alltests # works on my machine then how do I get this merge commit to es.mcs? Do I make that merge commit independently? ssh es.mcs cd petsc git checkout master git pull git merge jed/risky-business make alltests PETSC_ARCH=my-int64 make alltests PETSC_ARCH=my-complex-cxx ... # works for several PETSC_ARCH on Linux with GCC git push then come back to my machine and blast away the merge that I'm not going to use? git reset --hard @^ git pull Satish and Barry, is this really the workflow you're advocating? > Matt > > >> My point here is - there are quiet a few issues 'make alltests' would >> have found before merge to next [and should be fixed.] We need a make tests that takes less than five minutes that we expect everyone to run before merging. And probably that runs automatically using Pipelines or Travis or whatever. But that isn't a substitute for 'next'. >> Sure 'next' testing with all the variations do find other various >> issues. >> >> Skipping the first step - and using next for that basic testing just >> breaks it more - and things stay broken longer [and takes everyone >> elses time to figure out what broke next]. >> >> And everyone thinks someone else broken next - and its stays broken >> for weeks.. >> >> Satish >> > > > > -- > What most experimenters take for granted before they begin their > experiments is infinitely more interesting than any results to which their > experiments lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>