dolfin team mailing list archive

[Anders Logg <logg@xxxxxxxxx>]

On Thu, Feb 03, 2011 at 03:57:30PM -0800, Johan Hake wrote:
> On Thursday February 3 2011 15:46:33 Anders Logg wrote:
> > On Thu, Feb 03, 2011 at 11:57:36PM +0100, 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
> >
> > Too late. ;-)
> >
> > > 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
> >
> > That would be useful, but it's probably difficult to design such a
> > test. Perhaps it would be one single main.cpp that does a whole lot of
> > things.
>
> We have the unit tests. They should always be run before committing stuff. We
> could definitely increase the number of unit tests and the scope of them.

The problem is it takes time to (re)-build the tests. With just one
executable, we would have something that is quick enough that one
would always try it. (Not that I'm insisting that we must add this.)

--
Anders


> Johan
>
> > > 3. Making the test script more intelligent so that only the tests
> > > affected by the changes in code are run
> >
> > Sounds difficult. It would have to be very intelligent.
> >
> > > 4. Focusing on separating larger changes out into feature-branches (as
> > > before instead of personal-developer-branches)
> >
> > That's good but the problem is often that the feature branches tend to
> > be long-lived and result in large merges once it's time to merge them
> > back, and most other developers will not keep track of what's going on
> > in those branches.
> >
> > In particular, if I start working on a new feature in a separate
> > branch, it's likely Garth won't complain about the stuff I add until I
> > actually merge it into dolfin-main. If, on the other hand, I add it to
> > dolfin-logg, I signal that I intend to merge it as soon as it passes
> > the tests and it will trigger early feedback/discussion.
> >
> > (Maybe I should test this hypothesis by pushing GenericMatrix::operator(i,
> > j) to dolfin-logg. ;-)
> >