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
> 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
"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
"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
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
> >> >>
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
> 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
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
"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
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
"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]
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
> 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
> 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
> 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
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
> 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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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':
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
>
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
>
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)
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
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
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
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
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
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
> >
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
>> >
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
> >
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
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
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
> >
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
>
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 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:
$
57 matches
Mail list logo