dolfin team mailing list archive

["Marie E. Rognes" <meg@xxxxxxxxx>]

On 02/04/2011 10:18 AM, 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?


Yes. What takes time is the building (and running) of the demos. I 
consider this to be an important part of the testing because the unit 
tests seldomly break while the demos frequently do.


> > 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.


No. Hence the use of "focusing" ;-)


> 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.

I assume that the goal is to avoid introducing serious errors that takes 
significant effort to resolve. Not breaking the main buildbot is a way 
to accomplish this. As I see it, in the past there has been two main 
buildbot-breaking-patterns

- The developer actually run the tests on their installation before 
commiting, but the tests break for a different configuration. These 
errors are typically quickly resolved.

- The developer does not actually run the test suite either because it 
takes too long or because it is expected to fail as the implementation 
is at a tentative stage. In this case, the buildbot ends up failing for 
a while.

My intuitive solution would be to make it quicker to run the test suite, 
and/or separate implementation of features out into separate branches. 
Taking for instance the last hierarchical mesh feature as an example, it 
is easier for me to understand that this is what is going on if there is 
a dolfin-hierarchical-meshes (with a blueprint), than if this is 
something happening in the dolfin-logg branch.

In my view, creating personal-core-developer-branches goes in the other 
direction of the guidelines for "other developers"

    http://www.fenicsproject.org/developer/developer.html#contributing-code

But all that aside, basically, I'm just envisioning a lot of merging.

--
Marie