> 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. > Agreed. > I proposed creating the 'unstable' module to deal with (1). I really don't see the point of that. Two things: - first, the traditional approach is to have stable and unstable branches in SVN. The advantage of this is that we don't have to change all the calls (by changing or removing the module) if we want to move stuff from one place to another. - second, given the structure of IMP, there is no reason to put unstable and stable classes in different directories. We just mark which restraints and score states are stable and which are unstable, with, for example, a doxygen group. Moving something from one module to another is a pain for anyone who uses it.
> As for the kernel, clearly there is a need for guidelines for what lives > in there. I propose that the kernel is the IMP/*.h only. After all, that is the kernel... Everything else is optional.
> 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.) > For me, the important thing is to have NonbondedList, HierarchyDecorator (which the pdb reader depends on) and things like that somewhere were I can actually modify them and can commit patches in a reasonable fashion. Weird things like most of the ones in the list have no good reason to go in the IMP svn at all.