On Thu, Feb 03, 2011 at 11:57:36PM +0100, Marie E. Rognes wrote: > > On 3. feb. 2011, at 22:21, Anders Logg <l...@simula.no> 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. > 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. ;-) -- Anders _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : dolfin@lists.launchpad.net Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
