[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [IMP-dev] IMP reorg

Sounds good. It would be nice to have tests run on experimental too. Does one module failing really affect the others?

Also what does you comment about not putting things in experimental and then moving them to other modules mean? What exactly should go in experimental?

On Aug 30, 2008, at 1:04 AM, Ben Webb <> wrote:

OK, so given Daniel's and Keren's suggestions, here's what I'll do:

I will create three new modules: core, exp, and modeller. All developers
will have commit privileges to the core and exp modules. Modifications
to the kernel will still need to go through me. The other specific
modules will remain as they currently are - each with a given owner
(Keren for em and domino, me for modeller).

The core module will contain most of the code that most users and other projects use. Thus, most of the concrete classes currently in the kernel
(headers in subdirectories, not the top-level directory - e.g.
ConnectivityRestraint, RestraintSet, Daniel's nonbonded lists) will move
into the core module. API changes, deletions from, or additions of new
restraints, etc. to core (but not simply new methods to existing
classes, or cleanups of internals, etc.) should be announced on imp- dev
*before* the code is committed. (A general outline of new features is
fine - I just don't want to wake up one day and find 20,000 lines of
code in some entirely new set of classes.)

Code in the core module can be at various levels of maturity. The only
requirement is that the test cases pass "most of the time". (The general
rule of thumb should be that the nightly builds do not break for more
than 3 consecutive days.) As Daniel suggested, immature code should be
marked in a Doxygen group so that users can be aware.

The exp or experimental module is for code that is (scientifically)
experimental in nature. I will put particle refiners, cover bonds,
tunnel singleton score, and wormlike chain in there. This code should
still have test cases, of course, and be marked if it is immature just
like core is, but won't be built or tested as part of the nightly
builds, so there is less requirement that the tests pass all the time.
If a bunch of classes are envisaged for a given project (e.g. NPC
dynamics, a new optimizer, etc.) then probably the best thing is a
distinct module for that, where you'd have more flexibility, or even
something entirely external (e.g. Assembler).

Finally, the modeller module will contain what's currently in
modeller.py, plus anything else that requires Modeller, so that the
kernel and core can be built and tested without needing Modeller around.
(It will also get some additional Modeller-specific restraints which
I'll need to entice users away from Modeller.)

I will decide what goes in each module. Movements between modules should be exceedingly rare. It should certainly *not* be the case that somebody uses exp simply to write dodgy code that doesn't work, and then moves it
to core when the bugs are fixed. If stuff really needs to be moved
between modules, *I* will do it.

I will have the nightly build system email imp-dev if the nightly builds
fail. The culprit will then hopefully fix the problem ;) (with my
assistance if necessary).

I will create a Bugzilla instance to keep track of IMP bugs and wishlist
items. Bug fixes should, of course, come with a testcase to ensure the
bug stays fixed, and to some extent document the nature of said bug.

I will also work with Keren to put Assembler into the automatic build

I am reluctant to set too many rules, but there is an obvious
requirement that things rely reasonably stable, so that developers can
concentrate on the science and not on updating their code to work with
the most recent changes. It is my responsibility to keep things that
way, so I will revert patches (or users ;) if they cause extreme
breakage. I'll be relying on everyone to take care with their code and
its testcases. So while I cannot make everybody happy, I can do the next best thing and make everybody equally unhappy (hopefully only moderately
so ;).

Obviously there is a bunch of stuff to do, and I am not going to spend
my holiday weekend working on it. Plus, I will be in Chicago for most of next week. So probably things will be ready to move forward at the start
of the following week.

If anybody can point out an obvious problem with this solution, I may
have to think about (and delay) things some more. Otherwise, have a
relaxing and sunny Labor Day. ;)

"It is a capital mistake to theorize before one has data."
   - Sir Arthur Conan Doyle

IMP-dev mailing list