On Sat, 11 Nov 2017, Jed Brown wrote: > The proposal I'm objecting to, and that has prevented me from writing an > important letter of recommendation this morning during some precious > time while Joule is sleeping, was to eliminate 'next'. We wouldn't have > needed to exchange dozens of emails if you just wanted to make a better > system for catching the easy stuff before it gets to 'next'.
Sorry - didn't mean to disrupt your day. > > I think a half hour is way too long. The context switch is a problem. > If I work on something for PETSc during a particular hour of my day, I > want to be able to finish it. If I need to start 30 minutes of testing, > I will likely be occupied with other things by the time it is done and > won't be able to check up on it for several hours when I have 100 emails > and a baby to feed, etc. So realistically, I don't actually get to it > until the next day. But this inability to finish what might be a > five-minute task makes development less fun and puts big incentives on > not bothering with minor contributions/fixes. This was my thought regarding improving current workflow with next. Obviously its not acceptable to multiple folk [sure automation is better than manual work]. I think this is one more reason Barry wants to overhaul the testing infrastructure [aka throw away next - in his terms] I'm working arround the current next limitation by manually spending (manual) time with next-tmp testing. One of the things I'm doing is running the 1 hr tests manually myself [which feature developers should ideall run] - to determine what branches I want to have in next-tmp for the full testing. [so that there is a higher probability of clean builds - which is requred for graduating branches from testing to maint/master] > It also encourages writing a five minute email describing a solution > now, which "unexpectedly" evolves into a dozen emails and an hour of > time, instead of writing the 10-minute fix now because I know it would > need some slivers of time in the future, to push (which will likely fail > because someone else pushed, so I blast away the merge, pull, merge > again, compile again for sanity check but don't run alltests because I > hope not too much has changed, then push) and send the email reply > saying that the fix has been merged. Again you are advocating for automating most of 'local' testing stuff [which is part of my model of next] - wich I think Barry wants to do aswell in a different model. > Also, if my computer is busy running tests, I can't move on to the next > thing that needs to be done without having multiple PETSc clones. Since > I can't use existing PETSC_ARCH in a different PETSC_DIR, maintaining > lots of clones means lots of reconfiguring and rebuilding without the > benefits of ccache. All this sucks time. > > I'm sure I'm not the only one in a similar situation. We need an > effective set of tests that runs in less than five minutes so that we > can fix problems and move on rather than having lots of open threads > hanging around. All these are justfications agains my proposal for fixing current next - and in favor of Barry's new more automated testing. Note: There is no concrete info on this new model [except that it won't have next] - so maybe we can hold off discussion unitl we have something more concrete. Satish
