Petsc 'next' branch users,
I've recreated 'next' branch - and have a backup for current 'next' at
next-nov-2017
[This is eliminate some binary files - that got inadvertently
added. next-nov-2017 will be deleted at a later time]
So (next branch users) please do the following (in all your git
> On Nov 12, 2017, at 11:21 AM, Matthew Knepley wrote:
>
> On Sun, Nov 12, 2017 at 12:17 PM, Satish Balay wrote:
> On Sun, 12 Nov 2017, Matthew Knepley wrote:
>
> >
> > Have we tried histogramming test times? It would be nice to know how much
> >
On Sun, Nov 12, 2017 at 12:17 PM, Satish Balay wrote:
> On Sun, 12 Nov 2017, Matthew Knepley wrote:
>
> >
> > Have we tried histogramming test times? It would be nice to know how much
> > cumulative
> > time it takes to run 37%, 67%, 95%, etc.
>
> I'm not sure what
On Sun, 12 Nov 2017, Matthew Knepley wrote:
>
> Have we tried histogramming test times? It would be nice to know how much
> cumulative
> time it takes to run 37%, 67%, 95%, etc.
I'm not sure what 'histogramming test time' means.
All logs record time. And Karl's script summarizes those times on
On Sun, 12 Nov 2017, Jed Brown wrote:
>
> If we get basic testing before merging, the only breakage in 'next'
> should be the more interesting interactions. Most days should be clean.
This is what I've been sayin [in all the emails yesterday - wrt
improving current next testing]. Sure my
On Sun, Nov 12, 2017 at 11:45 AM, Jed Brown wrote:
> Satish Balay writes:
>
> > On Sun, 12 Nov 2017, Smith, Barry F. wrote:
> >
> >> If the testing/fixing would be faster if we bought more machines
> then decide what machines we need and we order them
Satish Balay writes:
> On Sun, 12 Nov 2017, Smith, Barry F. wrote:
>
>> If the testing/fixing would be faster if we bought more machines then
>> decide what machines we need and we order them now. Buying machines is far
>> better than wasting even more people time
On Sun, 12 Nov 2017, Smith, Barry F. wrote:
> If the testing/fixing would be faster if we bought more machines then
> decide what machines we need and we order them now. Buying machines is far
> better than wasting even more people time (which is much more expensive).
Its wading through
A time out would/should/does have clear indication that it is a timeout, so
it shouldn't be that.
Satish,
If the testing/fixing would be faster if we bought more machines then
decide what machines we need and we order them now. Buying machines is far
better than wasting even more
On Sun, 12 Nov 2017, Matthew Knepley wrote:
> > 2.not ok diff-ts_tutorials-ex45_3d_q2_r3
> >
> > I have no idea what is triggering this. [It will take a little while
> > for me to rebuild and reproduce - as the daybuild is now in progress]
>
> Is this just a timeout? Nothing in those branches
On Sun, Nov 12, 2017 at 10:36 AM, Satish Balay wrote:
> On Sun, 12 Nov 2017, Satish Balay wrote:
>
> > [Starting a new thread for this]
> >
> > Tonight's builds will be on 'next-tmp' with:
> >
> > $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp |
> sort)
On Sun, 12 Nov 2017, Satish Balay wrote:
> [Starting a new thread for this]
>
> Tonight's builds will be on 'next-tmp' with:
>
> $ git fetch -p && comm -12 <(git branch -r --merged origin/next-tmp | sort)
> <(git branch -r --no-merged origin/master | sort) |grep -v ' origin/next-tmp'
>
On Sat, Nov 11, 2017 at 9:40 PM, Satish Balay wrote:
> [Starting a new thread for this]
>
> Tonight's builds will be on 'next-tmp' with:
>
How easy would it be to setup a system that throttles (or in some way
intelligently selects) the branches
for 'next'? And when a branch
13 matches
Mail list logo