dolfin team mailing list archive

["Garth N. Wells" <gnw20@xxxxxxxxx>]

On 06/02/11 21:52, Anders Logg wrote:
> Can we revert back to running with 2 processes? 

I'd rather not. I got the buildbot green today with 3 processes, so it
defeats the purpose of separate branches we go and break it again.

> At least for a week or
> so until we have (1) settled in on the new repository organization and
> (2) finished the 0.9.10 release. My buildbot is currently red which
> makes me reluctant to merge although I believe my branch is clean.
>

The main branch is green with 3 processes, so it sounds like you need to
do some debugging.

Garth

> --
> Anders
> 
> 
> On Fri, Feb 04, 2011 at 11:12:53AM +0100, Johannes Ring wrote:
>> On Fri, Feb 4, 2011 at 10:41 AM, Anders Logg <logg@xxxxxxxxx> wrote:
>>> Are the buildbots essentially green now? One of them reports green
>>> while the others have timed out.
>>
>> Yes, they are essentially green. Some of them are timing out because
>> they run the unittests in parallel with 3 processes.
>>
>> Johannes
>>
>>>
>>>
>>> On Fri, Feb 04, 2011 at 09:18:12AM +0000, Garth N. Wells wrote:
>>>>
>>>>
>>>> On 03/02/11 22:57, Marie E. Rognes wrote:
>>>>>
>>>>> On 3. feb. 2011, at 22:21, Anders Logg <logg@xxxxxxxxx> wrote:
>>>>>
>>>>>> [\snip]
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>
>>>>> How about some or all of these:
>>>>>
>>>>> 1. Not introducing separate developer branches
>>>>>
>>>>> 2. Establishing a subset of tests that take a few minutes to run, so that we actually bother to run a set of tests before pushing to the main branch
>>>>>
>>>>
>>>> On my computer, the tests are pretty fast. Building the C++ demos is
>>>> slow because the test won't build in parallel (using -jX doesn't help
>>>> when building tests). Maybe Johannes could look at this?
>>>>
>>>>> 3. Making the test script more intelligent so that only the tests affected by the changes in code are run
>>>>>
>>>>> 4. Focusing on separating larger changes out into feature-branches (as before instead of personal-developer-branches)
>>>>>
>>>>
>>>> We didn't really do point 4 consistently before. For me, the idea is to
>>>> do more or what is suggested under point 4, but rather than registering
>>>> a new branch every time I work on something I have a permanent 'sandbox'
>>>> that I'm free to break.
>>>>
>>>> My take is that it's fine for the code in personal repositories to fail
>>>> the tests, which is inevitable when implementing bigger changes. What it
>>>> should do is avoid the problem that we've had when the buildbot is red
>>>> for days or weeks - one things breaks the buildbot, and before it's
>>>> fixed a bunch of other problems have been introduced.
>>>>
>>>> Garth
>>>>
>>>>>> Is here a way to merge via (A)?
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~dolfin
>>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: https://launchpad.net/~dolfin
>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>
>>>> _______________________________________________
>>>> Mailing list: https://launchpad.net/~dolfin
>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>>> Unsubscribe : https://launchpad.net/~dolfin
>>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~dolfin
>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~dolfin
>>> More help   : https://help.launchpad.net/ListHelp
>>>