<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Nov 11, 2017 at 12:53 PM, Satish Balay <span dir="ltr"><<a href="mailto:balay@mcs.anl.gov" target="_blank">balay@mcs.anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sat, 11 Nov 2017, Matthew Knepley wrote:<br>
<br>
> On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay <<a href="mailto:balay@mcs.anl.gov">balay@mcs.anl.gov</a>> wrote:<br>
><br>
> > On Sat, 11 Nov 2017, Matthew Knepley wrote:<br>
> ><br>
> > > > In the long term - Barry wants to get rid of next..<br>
> > ><br>
> > ><br>
> > > 1) I think next really prevents master from getting screwed up (witness<br>
> > > next)<br>
> > ><br>
> > > 2) I think we are actually finding interaction bugs there.<br>
> > ><br>
> > > Are those points wrong, or is there another way to do these things?<br>
> ><br>
> > Next is an intergration testing mechanism. The prerequisite for it [I<br>
> > think] is - one should test the branch properly before merging to<br>
> > next. However we are not doing proper testing before merge to next -<br>
> > and relying on next to do this part aswell.<br>
> ><br>
> > So with current next - it one has to figure out which branches are<br>
> > breaking the tests [takes time - which most of us are not doing] - and<br>
> > then hope it gets fixed quickly. Otherwise next stay broken for a long<br>
> > time [and other branches in next - which could be clean - don't<br>
> > receive sufficient confidence to graduate to master]<br>
> ><br>
> > So Barry's thought wrt getting next is to have a better way of testing<br>
> > feature branch one wants to test (i.e master+feature). Its not clear<br>
> > to me how many integration issues we've addressed with our current<br>
> > next model. [Its mostly been indvidual branch issues]<br>
> ><br>
> > Also if feature-1 and feature-2 are feature branches that are tested<br>
> > in next [wrt integration]. The following should be equivalent to<br>
> > testing 'master + feature1 + feature2' - aka current next model:<br>
> ><br>
> > 1. test master+feature1<br>
> > 2. success => merge feature1 to master<br>
> > 3. tets master+ feature2<br>
> > 3. success => merge feature2 to master<br>
> ><br>
> > Note: my next-tmp is an attempt to get closer to 'master+feature1'<br>
> > testing from 'master+feature1+feature2' testing [yeah - its more like<br>
> > master+2/3 branches in next-tmp vs master+10/15 branches in next.]<br>
> ><br>
> > Also I'm restarting next-tmp from a clean master when merging new set<br>
> > of branches to test. And throwing away branches with problems - and<br>
> > retest only after it has fixes [This way a broken branch does not keep<br>
> > next-tmp broken until it gets fixed.]<br>
><br>
><br>
> I don't think we have the resources to run full tests on every branch one<br>
> at a time. Do we?<br>
<br>
</div></div>We don't yet have this - but thats what I'm effectively doing manually<br>
with next-tmp [instead of 1 - its 2-3]<br>
<br>
Barry's thought here (I think) is - once we convert all the examples<br>
to the new test suite - it whould run much quicker - so might be able<br>
to a whole test suite on each branch.<br>
<br>
Or mabe have a way to have a few (fast) tests that can uncover most of<br>
the issues [aka travis-ci, pipelines] . Once the branch clears this -<br>
it can go into longer test queue (aka next equivalnet - but not next).<br>
<br>
None of this infrastructure currently exists.<br>
<br>
BTW: Ultimlately if you want to improve current next model - everyone<br>
has to do a 'make alltests DIFF=$PETSC_DIR/bin/petscdiff' for atleast<br>
one build that has relavent feature options enabled - before merging<br>
the feature branch to next.<br></blockquote><div><br></div><div>This does not agree with my experience (I think) for bug finding. It tends to</div><div>be other architectures (complex, 64-bit int, fortran) that fail for me, which</div><div>means running that for many builds, and my laptop is just not capable, and</div><div>furthermore that is why we have a farm of machines.</div><div><br></div><div>   Matt</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Note - this doesn't have to be on ones laptop - it can be on es.mcs.<br>
<span class="HOEnZb"><font color="#888888"><br>
Satish<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.caam.rice.edu/~mk51/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div>
</div></div>