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

[Jed Brown]

Satish Balay <balay at mcs.anl.gov> writes:

> 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]

We're confronted with a problem that 'next' has too much failing shit in
it and the solution is to get rid of 'next' because we trust that people
will be more careful when merging to 'master'?  I think that's absurd.
If we introduce a new system (CI, faster local tests, etc.) that
prevents broken shit from getting into 'next', such that 'next' is
always clean, then we could say the overhead is unnecessary.

>> > 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]

https://git-scm.com/blog/2010/03/08/rerere.html

>>  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.

No!  Bad topology because it makes your branch depend on whatever crap
has happened in 'next', thus preventing other branches from getting your
feature without also getting the rest of 'master'.  Also makes bisection
harder.  If there is a major conflict, you should merge exactly what is
needed.  If you just modified a line next to some unrelated modification
(our makefiles are TERRIBLE for this and must be exorcised) then there
is no need to merge 'master' into your 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.]

Huh?  Starting from 'master' is the right choice for a new feature.  NOT
for a bug fix.  But when developing a new feature, you don't want
repeated merges from 'master' because it increases the dependencies in
your branch and potentially introduces bugs and behavior changes that
have nothing to do with your feature.