[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:
>
>> >> 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.
>
> Agree - I think the goal is to automate as much as possible - and not rely
> on manual steps which folks would have to do on their own.
>
>> 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.
>
> Presumably thats one way to look at a model without next.
>
>> > 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',
>
> That was in refernce to a 'no-next' model - so there is no way it will
> depend on 'crap that happened in next'.

'master'.  Same point.

>> 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.
>
> Don't disagree here - but this not a justification for keeping the
> current next model with all the current problems.

Your proposed merge strategy (merging from upstream to ensure that an
automated system can merge back) creates the problems described here.
You proposed this merge model as necessary in a no-next model.

>> 
>> > 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 today - you had a branch [origin/jed/variadic-malloc] that started
> off maint - but was not destined for maint

I wasn't aware of the mswin const issue when I started it.

>>  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.
>
> You merge or rebase only if you have a merge conflict. If merge is not
> appropriate rebase can be. The merge conflict has to be resolved at
> some point.

Having a person do the merge works fine.