Keren Lasker wrote: > 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 ?? > The reviewed and tested code will be exactly the same as today. No real review and sporadic testing :-) More seriously, the practical differences will be negligible for most people other then we would have a convention for marking what is stable and what is not, something we currently lack. We will have some things that are stable and some things which are not. Stable things will be well tested and stable, things which are .
> 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. > Of course not. You are being silly.
People are conflating three things: - stability of the interface of certain files - location of the files - who can commit the files to svn
The three are entirely separate and we can make decisions about all three independently. Tying them together is is not necessarily a good thing.
> 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). > yes, all that should be in IMP_whatever_we call it and marked as stable and so infrequently changing.
> 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). > That will just result in more code that has to be modified when we reorganize things. Wouldn't you rather write tests against something that is not going to change immediately?