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

Satish Balay balay at mcs.anl.gov
Fri Nov 10 15:50:33 CST 2017

On Fri, 10 Nov 2017, Richard Tran Mills wrote:

> Hi Satish,
> Thanks for taking the initiative to switch to testing next-tmp to help
> clear up the constipation with moving things into master. It looks like
> there hasn't been any graduation of the branches you've been putting into
> next-tmp in a few days, though. Is this just because you haven't had time
> to do any more of these merges, or are the tests breaking with next-tmp now?
> If I go to the dashboard at
> http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/11/10/next.html,
> is this showing me the info for 'next' or 'next-tmp'? If it is showing me
> 'next', how do I find the results for 'next-tmp'?

Sorry - I haven't been checking properly on this.

The last next-tmp build was on:


There were some errors - which I didn't debug.

$ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) <(git branch -r --no-merged origin/master | sort)

[Its probably one of the above branches. I'll look for it - and then
merge the others to master.]

So I reverted the tests back to next stating 08


Yeah - next vs next-tmp is not clearly visible here - but if you go to
any of the logs - you'll see next or next-tmp on the filename.

For eg:

> If we think a branch may be ready for 'master', should we still be merging
> to 'next', given it's current broken state?

For now - I would say - if you now a bunch of branches that you think
are ready (master) - I can schedule a next-tmp test on them to verify.

The tricky thing here is for all of us to be aware of this - and not
assume next is tested - and merge then go ahead and merge the wrong
branches to master.

> Lastly, a question for everyone: If someone knows that they have merged
> something into 'next' that has broken the builds or tests, and it is going
> to be a while before this is fixed, should they revert that changeset in
> 'next'? I see some reverts in the 'next' logs, but not that many. Maybe
> this is because it's not always easy to tell if one's particular changeset
> broke things when there are all these other changes being merged.

Reverts are tricky - hence I avoid them. But if needed - we could do
that [it requires extra care in the workflow - i.e when you have to
merge back later - or revert again for the second time etc.]

Alternative is to delete/recreate next - if needed. [but it requires
all next users to do this delete/recreation]

In the long term - Barry wants to get rid of next..


More information about the petsc-dev mailing list