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

Re: [IMP-dev] thoughts on the reorg




On Aug 27, 2008, at 10:18 AM, Daniel Russel wrote:

Ben Webb wrote:
Daniel Russel wrote:

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.


An SVN branch is just a directory anyway. And I'd rather not branch all
of IMP.

- second, given the structure of IMP, there is no reason to put unstable
and stable classes in different directories.


Perhaps we should not call this module 'unstable', because you seem to be getting the wrong end of the stick here; perhaps 'misc' is a better name. The intention is for it to be used for kernel additions that don't happily sit anywhere else. Because the access is more open, it is likely that people will put in unstable, untested code, but I certainly don't
think we should encourage that.

So to make the next iteration of the proposal:
1) the IMP kernel module is simplified to contain only the IMP kernel
proper which is basically some subset of IMP/*.h, perhaps without
decoratorbase and ParticleRefiner.

2) We add a module IMP_misc or IMP_core which contains all the existing
restraints, states and decorators and stuff and has a more open access
policy.

3) We adopt a convention of labelling things in IMP_misc as to their
maturity. Perhaps "stable" for objects whose interfaces are unlikely to
change and which are well tested and "unstable" for newer and less
mature things and "unsupported" for things which are there because they
may be of interest, but the level of interest is unclear and unless
people say something they may not be actively developed.

4) IMP_misc will have an open commit policy, but convention that changes
to the interface of things marked stable should be proceeded by a
warning on imp-dev and that tests on them must not be broken.

I have a mostly marked version of the non-kernel imp code so I can
easily produce the code for an IMP_misc module given a place to put it
in SVN. Once it is in place, then we can remove the stuff from kernel.

So the suggestion is that reviewed and tested code will only be a few *.h files? and the IMP_misc module (labeled stable, unstable or unsupported) is all of IMP ?? Assembler ( Frido's and my 26S stuff) , for example, relays on code that according to the last proposal would be part of IMP_misc (restraints, optimizers , the hierarchy) , which means that we can expect the interfaces to change on a daily basis without any sufficient tests on the python level, cluster etc. It does not make sense to encourage people to rely on the IMP kernel when it is going to be mostly unstable. I think that there should be some level between kernel and IMP_misc, which will include the core functionalities ( basic optimizers, restraints, hierarchy and atomic stuff). If we are going to continue with the suggested plan, we have to have many more test-cases and as Ben suggested assembler stuff should probably be part of the test-cases. I would really really appreciate holding the reorg until we'll have assembler test-cases ready for IMP (probably in the next two weeks).

_______________________________________________
IMP-dev mailing list

https://salilab.org/mailman/listinfo/imp-dev