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

[Satish Balay]

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

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

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

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

Satish