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

[Jed Brown]

"Smith, Barry F." <bsmith at mcs.anl.gov> writes:

>> On Nov 11, 2017, at 11:33 AM, Jed Brown <jed at jedbrown.org> wrote:
>> 
>> Matthew Knepley <knepley at gmail.com> writes:
>> 
>>>> Alternative is to delete/recreate next - if needed. [but it requires
>>>> all next users to do this delete/recreation]
>>>> 
>>>> In the long term - Barry wants to get rid of next..
>>> 
>>> 
>>> 1) I think next really prevents master from getting screwed up (witness
>>> next)
>> 
>> Agree.  Next provides lots of value to PETSc, both raising the quality
>> of 'master' and enabling testing of interactions and easy access to
>> bleeding edge features.
>
>   Nonsense, nonsense and more nonsense. Next has just proven to be a big pain (especially for Satish) with a micro amount of proven usefulness.

Removing next without a reliable substitute that ensures quality control
would be a disaster for the stability of 'master', and thus for everyone
trying to develop new features.  That's what we had before switching to
Git and it was a mess.

>> 
>>> 2) I think we are actually finding interaction bugs there.
>>> 
>>> Are those points wrong, or is there another way to do these things?
>> 
>> Make infallible tests that run synchronously on every merge candidate.
>> It sounds nice in theory until you work out all the implications and
>> then just doesn't look practical.
>
>    What are all the implications that won't make it practical, itemize? 
>
>    Our current model where shit sits in next for weeks and Satish
>    spends hours a day unwinding next-tmp crap is unacceptably bad 

Yes, so let's fix it by ensuring that whatever tests need to happen
before merging to 'next' actually happen.

>    and unfixable

If we can't make 'next' be not constantly broken, we have no business
pushing to 'master' before 'next'.

>    so resistance to trying something new strikes me as irrational.

It isn't enough to be different.