dolfin team mailing list archive

[Johan Hake <johan.hake@xxxxxxxxx>]

On Thursday February 3 2011 16:02:32 Anders Logg wrote:
> 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.)

  python test.py --only-python

works for me ;)

Johan

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