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. > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >