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

2017-11-13 Thread Scott Kruger
On 11/11/17 11:47 AM, Jed Brown wrote: 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 fundamental problem here is that we aren't accurate enough at placing blame and getting the appropriate

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 3:49 PM, Jed Brown wrote: > > "Smith, Barry F." writes: > >> You are arguing against a change in the abstract because you love >> next! You are making up stray men and attacking them. Wait until >> there is a real proposal

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

2017-11-11 Thread Jed Brown
"Smith, Barry F." writes: >You are arguing against a change in the abstract because you love >next! You are making up stray men and attacking them. Wait until >there is a real proposal then point out flaws and make suggestions >on how to improve it. There is

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

2017-11-11 Thread Jed Brown
"Smith, Barry F." writes: > Jed wrote (with my ()) > > I'm sure I'm not the only one in a similar situation. We need an > effective set of tests that runs in less than five minutes (on all systems > with all compilers) so that we > can fix problems and move on rather than

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > Satish Balay 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 > >> >>

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

2017-11-11 Thread Smith, Barry F.
Let's please all stop wasting time arguing about next! We can argue when there is something to argue about. Not now. > On Nov 11, 2017, at 3:27 PM, Balay, Satish wrote: > > On Sat, 11 Nov 2017, Jed Brown wrote: > >> Removing next without a reliable substitute that

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 3:26 PM, Jed Brown wrote: > > "Smith, Barry F." writes: > >> There is no reason to waste time protesting the attempt to change >> to the new model. The attempt will happen as soon as we have the >> new test harness fully

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > Removing next without a reliable substitute that ensures quality control > would be a disaster for the stability of 'master', and thus for everyone > trying to develop new features. That's what we had before switching to > Git and it was a mess. Sorry if

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

2017-11-11 Thread Jed Brown
"Smith, Barry F." writes: >There is no reason to waste time protesting the attempt to change >to the new model. The attempt will happen as soon as we have the >new test harness fully working. So help out or get out of the way. I can't help convert tests if I'm

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

2017-11-11 Thread Jed Brown
Satish Balay 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

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

2017-11-11 Thread Jed Brown
"Smith, Barry F." writes: >> On Nov 11, 2017, at 11:33 AM, Jed Brown wrote: >> >> Matthew Knepley writes: >> Alternative is to delete/recreate next - if needed. [but it requires all next users to do this delete/recreation]

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

2017-11-11 Thread Smith, Barry F.
Jed wrote (with my ()) I'm sure I'm not the only one in a similar situation. We need an effective set of tests that runs in less than five minutes (on all systems with all compilers) so that we can fix problems and move on rather than having lots of open threads hanging around. Sure, this

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 11:49 AM, Jed Brown wrote: > > Matthew Knepley writes: > >> On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay wrote: >> >>> On Sat, 11 Nov 2017, Matthew Knepley wrote: >>> > In the long term - Barry wants to

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 11:46 AM, Matthew Knepley wrote: > > On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay wrote: > On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > > In the long term - Barry wants to get rid of next.. > > > > > > 1) I think next really

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 11:33 AM, Jed Brown wrote: > > Matthew Knepley writes: > >>> 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

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

2017-11-11 Thread Smith, Barry F.
There is no reason to waste time protesting the attempt to change to the new model. The attempt will happen as soon as we have the new test harness fully working. So help out or get out of the way. Barry > On Nov 11, 2017, at 12:06 PM, Satish Balay wrote: > > On

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

2017-11-11 Thread Smith, Barry F.
> On Nov 11, 2017, at 11:17 AM, Matthew Knepley wrote: > > On Fri, Nov 10, 2017 at 4:50 PM, Satish Balay wrote: > > On Fri, 10 Nov 2017, Richard Tran Mills wrote: > > > Hi Satish, > > > > Thanks for taking the initiative to switch to testing next-tmp to

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > The proposal I'm objecting to, and that has prevented me from writing an > important letter of recommendation this morning during some precious > time while Joule is sleeping, was to eliminate 'next'. We wouldn't have > needed to exchange dozens of emails

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

2017-11-11 Thread 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

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

2017-11-11 Thread Jed Brown
Satish Balay writes: > On Sat, 11 Nov 2017, Jed Brown wrote: > >> > If you are running 'make alltests' on your laptop - then you don't need to >> > test on es - before merge to maint. >> >> alltests takes hours and doesn't catch weird configurations -- you need >> different

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

2017-11-11 Thread Jed Brown
Satish Balay writes: > On Sat, 11 Nov 2017, Jed Brown wrote: > >> > 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 fundamental problem here is that we aren't

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > > If you are running 'make alltests' on your laptop - then you don't need to > > test on es - before merge to maint. > > alltests takes hours and doesn't catch weird configurations -- you need > different PETSC_ARCH for that. It is normal to at least

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > > 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 fundamental problem here is that we aren't accurate enough at > placing blame and getting the

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

2017-11-11 Thread Jed Brown
Satish Balay writes: > On Sat, 11 Nov 2017, Jed Brown wrote: > >> >> Merging is synchronous. If I do >> >> git checkout master >> git pull >> git merge jed/risky-business >> make alltests # works on my machine > > Note: this is my recommendation for the *currentK

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

2017-11-11 Thread Jed Brown
Satish Balay writes: > On Sat, 11 Nov 2017, Matthew Knepley wrote: > >> And that makes my point. The time for me to login to cg, set >> everything up, and run the tests should be automated, and in fact we >> already did that for next, which is what should be used. > > You can

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > > Merging is synchronous. If I do > > git checkout master > git pull > git merge jed/risky-business > make alltests # works on my machine Note: this is my recommendation for the *currentK next model. If you are running 'make alltests' on your

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

2017-11-11 Thread Jed Brown
Satish Balay writes: > On Sat, 11 Nov 2017, Jed Brown wrote: > >> Satish Balay 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?

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

2017-11-11 Thread Jed Brown
Matthew Knepley writes: > On Sat, Nov 11, 2017 at 1:15 PM, Satish Balay wrote: > >> On Sat, 11 Nov 2017, Matthew Knepley wrote: >> >> > > >> > > BTW: Ultimlately if you want to improve current next model - everyone >> > > has to do a 'make alltests

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Matthew Knepley wrote: > And that makes my point. The time for me to login to cg, set > everything up, and run the tests should be automated, and in fact we > already did that for next, which is what should be used. You can automate an ssh command run a test on cg - [if you

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Jed Brown wrote: > Satish Balay 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

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

2017-11-11 Thread Jed Brown
Satish Balay 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

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > > BTW: Ultimlately if you want to improve current next model - everyone > > has to do a 'make alltests DIFF=$PETSC_DIR/bin/petscdiff' for atleast > > one build that has relavent feature options enabled - before merging > > the feature branch to

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

2017-11-11 Thread Satish Balay
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

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

2017-11-11 Thread Matthew Knepley
On Sat, Nov 11, 2017 at 12:53 PM, Satish Balay wrote: > On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay > wrote: > > > > > On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > > > > > > In the long term - Barry

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Matthew Knepley wrote: > On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay wrote: > > > On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > > > > In the long term - Barry wants to get rid of next.. > > > > > > > > > 1) I think next really prevents master from

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

2017-11-11 Thread Jed Brown
Matthew Knepley writes: > On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay wrote: > >> On Sat, 11 Nov 2017, Matthew Knepley wrote: >> >> > > In the long term - Barry wants to get rid of next.. >> > >> > >> > 1) I think next really prevents master from getting

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

2017-11-11 Thread Matthew Knepley
On Sat, Nov 11, 2017 at 12:37 PM, Satish Balay wrote: > On Sat, 11 Nov 2017, Matthew Knepley wrote: > > > > In the long term - Barry wants to get rid of next.. > > > > > > 1) I think next really prevents master from getting screwed up (witness > > next) > > > > 2) I think we

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Matthew Knepley wrote: > > In the long term - Barry wants to get rid of next.. > > > 1) I think next really prevents master from getting screwed up (witness > next) > > 2) I think we are actually finding interaction bugs there. > > Are those points wrong, or is there

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

2017-11-11 Thread Jed Brown
Matthew Knepley writes: >> 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.. > > > 1) I think next really prevents master from getting screwed up

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

2017-11-11 Thread Jed Brown
Satish Balay writes: >> origin/jed/variadic-malloc > > http://ftp.mcs.anl.gov/pub/petsc/nightlylogs/archive/2017/11/11/filtered-make_next-tmp_arch-mswin-uni_ps4.log > C:\cygwin64\home\petsc\PETSC~3.CLO\src\vec\is\utils\vsectionis.c(2380): > warning C4090: 'function':

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

2017-11-11 Thread Matthew Knepley
On Fri, Nov 10, 2017 at 4:50 PM, Satish Balay wrote: > > 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 >

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

2017-11-11 Thread Satish Balay
On Sat, 11 Nov 2017, Satish Balay wrote: > On Fri, 10 Nov 2017, Satish Balay wrote: > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > <(git branch -r --no-merged origin/master | sort) > origin/hongzh/add-tstraj-filename merged to master >

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

2017-11-10 Thread Satish Balay
On Fri, 10 Nov 2017, Satish Balay wrote: > [Its probably one of the above branches. I'll look for it - and then > merge the others to master.] I've changed the nightlybuilds back to next-tmp. Branches to be tested are: $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort)

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

2017-11-10 Thread Satish Balay
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

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

2017-11-10 Thread Jed Brown
Richard Tran Mills writes: > 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

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

2017-11-10 Thread Richard Tran Mills
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

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

2017-11-07 Thread Satish Balay
I think so. Also do 'make alltests DIFF=$PETSC_DIR/bin/petscdiff' [esp with feature changes that are likely to break things] and fix regressions - before a PR or a merge to next. But I don't think most of us are doing this.. Satish On Mon, 6 Nov 2017, Patrick Sanan wrote: > Should this be

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

2017-11-06 Thread Satish Balay
On Mon, 6 Nov 2017, Satish Balay wrote: > On Sun, 5 Nov 2017, Satish Balay wrote: > > > > origin/jed/fix-stdout-attr-delete > > > origin/jed/pastix-comm > > > origin/mark/fix-mat > > > > These are now merged to master. > > Jed, Mark, > > The above branches appear to have started from

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

2017-11-06 Thread Satish Balay
On Mon, 6 Nov 2017, Jed Brown wrote: > > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > > <(git branch -r --no-merged origin/master | sort) > > origin/barry/delete-adjoint-trajectory > > origin/barry/remove-unneeded-use-of-petscdatatype > >

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

2017-11-06 Thread Jed Brown
Satish Balay writes: > On Sun, 5 Nov 2017, Satish Balay wrote: > >> > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | >> > sort) <(git branch -r --no-merged origin/master | sort) >> > origin/hongzh/copy_l2g_stencil >> >

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

2017-11-06 Thread Satish Balay
On Sun, 5 Nov 2017, Satish Balay wrote: > > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > > <(git branch -r --no-merged origin/master | sort) > > origin/hongzh/copy_l2g_stencil > > origin/jed/fix-dmcoarsenhookadd-identical > >

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

2017-11-06 Thread Patrick Sanan
Should this be considered standard practice for all contributors? On Mon, Nov 6, 2017 at 4:19 PM, Satish Balay wrote: > On Sun, 5 Nov 2017, Satish Balay wrote: > > > > origin/jed/fix-stdout-attr-delete > > > origin/jed/pastix-comm > > > origin/mark/fix-mat > > > > These

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

2017-11-06 Thread Satish Balay
On Sun, 5 Nov 2017, Satish Balay wrote: > > origin/jed/fix-stdout-attr-delete > > origin/jed/pastix-comm > > origin/mark/fix-mat > > These are now merged to master. Jed, Mark, The above branches appear to have started from maint. Are they destined to maint? If so it would be good to

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

2017-11-05 Thread Satish Balay
On Sun, 5 Nov 2017, Satish Balay wrote: > On Sat, 4 Nov 2017, Satish Balay wrote: > > > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > > <(git branch -r --no-merged origin/master | sort) > > origin/barry/fix-matsettype-forsubclasses > >

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

2017-11-05 Thread Satish Balay
On Sat, 4 Nov 2017, Satish Balay wrote: > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > <(git branch -r --no-merged origin/master | sort) > origin/barry/fix-matsettype-forsubclasses > origin/jed/fix-stdout-attr-delete > origin/jed/pastix-comm >

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

2017-11-04 Thread Satish Balay
On Sat, 4 Nov 2017, Satish Balay wrote: > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort) > <(git branch -r --no-merged origin/master | sort) > origin/balay/fix-mkl-batch-error/maint > origin/barry/fix-lto_library-option-maint >

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

2017-11-03 Thread Satish Balay
PETSc integrator group, next builds have been broken for the past few weeks - preventing graduation of potentially clean branches to maint/master. So I've switched nightlybuilds from next to next-tmp to test fewer branches at a time [and hopefully graduate them]. Tonights builds are with: $