Anyway, we should get something done soon, this is taking a bit long
given that few people are inclined to comment.
It seems to me the reasonable options are:
1) an IMP kernel which is just the kernel (so the classes in IMP/*.h)
and then various modules with other classes including a core module
which has most of the current restraints and is open to everyone to
commit things.
2) use a more normal revision control system with release and unstable
branches. Anyone can commit to the unstable branch and Ben is in charge
of moving things from unstable to release.
As always, I prefer the second, especially since IMP is fairly modular
and so one can pick and choose which unstable things one uses use.
So, one or two?
Daniel Russel wrote:
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.