[petsc-dev] broken nightlybuilds (next vs next-tmp)

[Satish Balay]

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