[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 don't think we have the resources to run full tests on every branch one
> >> > at a time. Do we?
> >> 
> >> No,
> >
> > Well the hope is - after the migration to new test suite is complete
> > the cost of a full test run is lower. And we could somehow do fewer
> > tests to capture most issues.
> >
> >> and after each merge of a branch to 'master', the prospective merge
> >> of other branches would need to be retested.  But the idea that the
> >> automated test suite is infallible is also flawed.
> >
> > Well arn't we relying on 'automated testing' with the current next
> > model?
> 
> Some of us also run 'next' in daily work and fix issues as they appear
> in that context.  There is also significant convenience in there being
> one place we can go to reproduce all issues.

If you need next for some other purpose than graduation branches to
master - than you can crate a workflow [with next or a different
branch] for that purpose.

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 other option I've been comtemplating [wrt next-tmp] is - test all
feature branches for barry one day - and all from matt - the next day
etc. Then I don't have to figure out which commit broke things. It
would be one of the branches of that author - so they can deal with
figureing out what broke.

[and then throw this away - and test some of the branches the next day]

> When testing separate branches, it isn't enough to merely test their
> head, we would have to test the result of a candidate merge. 

Yes - thats what I've been saying - test 'master + feature-1'

> If there
> are any conflicts, that merge needs to be done manually, but where would
> we put it for automated testing?

If there are conflicts - there wont' be a merge or a test until the
author resolves the conflict. [via a merge or rebase]. This can go on
until the feature branch gets merged to master [or maint]

>  Make a new branch 'candidate-merge-jed/foo-to-master' and push
> that, then look for results several hours or a day later?  With
> 'next', we make merges to one place and don't need a different
> workflow for no-conflict versus conflicted merges.

Yes there has to be some mechanism to say the branch
'candidate-merge-jed/foo-to-master' is ready for master. Most folks
appear to use PRs for this workflow. But we don't. And Barry doesn't
like it. So instead of PR - branches can be placed in some
placeholder.

For ex: I'm currently getting branch list from 'next' - selecting a
few of them for next-tmp tests.

Wrt merge conflicts - an author is primarily responsible to resolve
them wrt master. If master changes with new feature - which causes
conflict - another merge conflict resolution is required - it should
be the same amount of work as doing this with next.

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]

Satish