"Smith, Barry F." <bsm...@mcs.anl.gov> writes: >> On Nov 11, 2017, at 11:33 AM, Jed Brown <j...@jedbrown.org> wrote: >> >> Matthew Knepley <knep...@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.