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

[Satish Balay]

On Sat, 11 Nov 2017, Jed Brown wrote:

> > The way I see it - a broken next [where folks can't easily figure out
> > who or which commit is responsible for the brakages] - doesn't help
> > much..
> 
> The fundamental problem here is that we aren't accurate enough at
> placing blame and getting the appropriate person to fix it.  It doesn't
> help that we are a distributed team and have plenty of our own
> obligations.  I can't fix something while I'm teaching class or meeting
> with students, for example.  But we should all be able to get to it
> within a day, either to withdraw the branch from 'next' or to actually
> fix it.

Another justifcation for a different model [which Barry wants to
pursue] - where one doesn't have to rely one separating out issues
from a jumble. And not relying on folks fixing next breakages
immediately.

> I think a lot of our noise in 'next' is "stupid shit", like compilation
> failing on some architecture.  Automating a very limited test suite
> running on PRs within minutes should help a lot to deal with that.  More
> subtle interaction problems can and should continue to be dealt with via
> 'next'.

My claim here is if everyone runs 'make alltests' on alteast one build
[whatever their prefered build is] - it will cut down most of the
nosie. [yeah this is different noise than what you are refering to]

I think Compiler warnings/errors are presumably easy to fix. Broken
examples are harder to chase down. [esp when it happens on every build
- the logs get unreadable]

> > Note: with next - any merge resolution that gets done has to be
> > repeated when the branch gets merged to master. [Since git doesn't
> > keep trak of this by default] the second merge to master is not always
> > the same as the first one in next. This causes merge conflict when
> > master gets merged to next [yeah I've seen this a few times]
> 
> If the same person does the merge, the same resolution (assuming it
> still works) comes automatically.

True - but doesn't happen all the time - and some of us are forgetting
how we merged the first time. [yeah - you mentioned some git option to
remember - that one can use - but none of us are using it]

>  The point is that having a bunch of candidate merge branches that
> need to be ported around to different machines will be a far bigger
> mess than we have now, and still doesn't fix the problems.

Not sure what you mean here by 'bunch of candidate merge branches that
need to be ported around'

If you need to resolve a merge - you merge 'master' to your feature
branch and resolve it [or rebase it].  The resolution is in your
feature branch.

Sure this breaks your current workflow of staring with oldest possible
version of petsc for any new feature [not latest master]. But none of
us are using that model - and the burdens of that model are not worth
it [as we are not really using the benefits of it - like some of the
other projects that are using this model.]

Satish