Sounds good. It would be nice to have tests run on experimental too. Does one module failing really affect the others?
Also what does you comment about not putting things in experimental and then moving them to other modules mean? What exactly should go in experimental?
On Aug 30, 2008, at 1:04 AM, Ben Webb ben@salilab.org wrote:
> OK, so given Daniel's and Keren's suggestions, here's what I'll do: > > I will create three new modules: core, exp, and modeller. All > developers > will have commit privileges to the core and exp modules. Modifications > to the kernel will still need to go through me. The other specific > modules will remain as they currently are - each with a given owner > (Keren for em and domino, me for modeller). > > The core module will contain most of the code that most users and > other > projects use. Thus, most of the concrete classes currently in the > kernel > (headers in subdirectories, not the top-level directory - e.g. > ConnectivityRestraint, RestraintSet, Daniel's nonbonded lists) will > move > into the core module. API changes, deletions from, or additions of new > restraints, etc. to core (but not simply new methods to existing > classes, or cleanups of internals, etc.) should be announced on imp- > dev > *before* the code is committed. (A general outline of new features is > fine - I just don't want to wake up one day and find 20,000 lines of > code in some entirely new set of classes.) > > Code in the core module can be at various levels of maturity. The only > requirement is that the test cases pass "most of the time". (The > general > rule of thumb should be that the nightly builds do not break for more > than 3 consecutive days.) As Daniel suggested, immature code should be > marked in a Doxygen group so that users can be aware. > > The exp or experimental module is for code that is (scientifically) > experimental in nature. I will put particle refiners, cover bonds, > tunnel singleton score, and wormlike chain in there. This code should > still have test cases, of course, and be marked if it is immature just > like core is, but won't be built or tested as part of the nightly > builds, so there is less requirement that the tests pass all the time. > If a bunch of classes are envisaged for a given project (e.g. NPC > dynamics, a new optimizer, etc.) then probably the best thing is a > distinct module for that, where you'd have more flexibility, or even > something entirely external (e.g. Assembler). > > Finally, the modeller module will contain what's currently in > modeller.py, plus anything else that requires Modeller, so that the > kernel and core can be built and tested without needing Modeller > around. > (It will also get some additional Modeller-specific restraints which > I'll need to entice users away from Modeller.) > > I will decide what goes in each module. Movements between modules > should > be exceedingly rare. It should certainly *not* be the case that > somebody > uses exp simply to write dodgy code that doesn't work, and then > moves it > to core when the bugs are fixed. If stuff really needs to be moved > between modules, *I* will do it. > > I will have the nightly build system email imp-dev if the nightly > builds > fail. The culprit will then hopefully fix the problem ;) (with my > assistance if necessary). > > I will create a Bugzilla instance to keep track of IMP bugs and > wishlist > items. Bug fixes should, of course, come with a testcase to ensure the > bug stays fixed, and to some extent document the nature of said bug. > > I will also work with Keren to put Assembler into the automatic build > system. > > I am reluctant to set too many rules, but there is an obvious > requirement that things rely reasonably stable, so that developers can > concentrate on the science and not on updating their code to work with > the most recent changes. It is my responsibility to keep things that > way, so I will revert patches (or users ;) if they cause extreme > breakage. I'll be relying on everyone to take care with their code and > its testcases. So while I cannot make everybody happy, I can do the > next > best thing and make everybody equally unhappy (hopefully only > moderately > so ;). > > Obviously there is a bunch of stuff to do, and I am not going to spend > my holiday weekend working on it. Plus, I will be in Chicago for > most of > next week. So probably things will be ready to move forward at the > start > of the following week. > > If anybody can point out an obvious problem with this solution, I may > have to think about (and delay) things some more. Otherwise, have a > relaxing and sunny Labor Day. ;) > > Ben > -- > ben@salilab.org http://salilab.org/~ben/ > "It is a capital mistake to theorize before one has data." > - Sir Arthur Conan Doyle > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev