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

[Satish Balay]

On Sat, 11 Nov 2017, Jed Brown wrote:

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

no you are assuming 'master-only' old model. None of my emails refer to that.

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

I was refering to this branch as an example that started off maint
(not master) but destined to master.

 I assumed that was your model of staring new feature branch at oldest
possible snapshot - so that it could be merge to maint - in case
someone wants that feature in maint. If that was not the case - lets
go past this.

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

Sure - hence the author is responsible for resolving potential merge
conflicts (as I mentined before).

After that - any automated system can take over and so stuff (merges
or not) that it deems neecessary for the testing model that we adopt.

BTW: right now [with the current next model] authors are not doing the
merge conflict resolution. Integrators are doing this. [Sure in our
case we are both integrators and authors - so don't see the
difference]

Satish