Daniel Russel wrote: > Most of the restraints and other useful functionality are moving out of > the kernel. Currently the idea is that they go into a module called dsr > (for lack of another name) which would be modifiable by everyone. Only > the angle restraints and a couple of other non-kernel objects would be > left in the kernel. I propose instead we call it "basic" and move all > existing restraints into it. That way we have less random split of code > between modules. After all, does anyone want to remember that > "DistanceRestraint" is in IMP but "DistancePairScore" or > "NonbondedListScoreState" is part of IMP.dsr?
Let's not confuse the issues here. There are two quite separate issues: 1. Easier access to SVN for people wanting to try new methods. 2. Decision on what should and should not lie in the kernel.
I proposed creating the 'unstable' module to deal with (1). As for (2), the kernel interfaces are comparatively stable, so in the short term at least I don't envisage large changes there. (There is, of course, nothing to stop you simply copying a kernel function into unstable and developing it there. Once it's stable, the kernel version can be updated, or it can be moved into a stable module.)
Before we get too carried away with modules, let's define some ground rules: 1. Modules group classes and functions by similar functionality, not by author, and should be named accordingly. For example, the 'em' module contains only classes for cryo EM fitting. 2. Each module has a responsible owner or group. 3. Modules should still obey IMP coding standards, code review is still encouraged if possible, and major API changes should be advertised on the IMP-dev mailing list. 4. Modules can link with external libraries that the IMP kernel does not link with. However, these libraries must be publicly accessible (so that others can use the module) and not be incompatible with the IMP license (for example, no GPL libraries, but BSD or LGPL is OK). 5. For developmental code that doesn't obviously fit into a neat category, the 'unstable' module is writable by all.
As for the kernel, clearly there is a need for guidelines for what lives in there. For now, however, we could start by moving the experimental stuff that is not relied upon by other projects into the 'unstable' module. (Seems that this would be some or all of CoverBondsScoreState, ParticleRefiner and subclasses, BrownianDynamics, RefineOncePairScore, TunnelSingletonScore, WormLikeChain.)
Ben