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