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
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
Daniel Russel wrote: > Sounds good. It would be nice to have tests run on experimental too.
Well, the intention was to run the tests but not fail the build if the tests fail. But if people don't look at the build logs, it doesn't make a lot of difference whether the tests are run or not...
> Does one module failing really affect the others?
Sure - the build system only updates the copy in /diva1 if all of the modules succeed, so everything is in a consistent state.
> 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?
I mean a given feature (e.g. a restraint) should be expected to live in a single module for its entire lifetime. The exp module is for scientifically experimental features, as opposed to the core module which includes features of general utility (e.g. distance restraints). New features are proposed on imp-dev before going in, at which point I can determine whether they belong in core, exp, or a more specific module.
Ben
On Sep 24, 2008, at 9:53 AM, Ben Webb wrote:
> Daniel Russel wrote: >> Sounds good. It would be nice to have tests run on experimental too. > > Well, the intention was to run the tests but not fail the build if the > tests fail. But if people don't look at the build logs, it doesn't > make > a lot of difference whether the tests are run or not... If someone is interested in making sure there code builds on other platforms they will look :-) If not, no great loss unless the more obscure platform test machines are overloaded...
>> >> 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? > > I mean a given feature (e.g. a restraint) should be expected to live > in > a single module for its entire lifetime. The exp module is for > scientifically experimental features, as opposed to the core module > which includes features of general utility (e.g. distance restraints). > New features are proposed on imp-dev before going in, at which point I > can determine whether they belong in core, exp, or a more specific > module. I think I am still confused, is the experimental for any restraints that deal with experimental data or for experimental restraints (i.e. ones whose functionality is not yet completely nailed down)? If it is the former, I misunderstood, but it should definitely have its tests run. If the latter, it seems quite reasonably to run tests on it, but not have the tests break the build. And it also seems reasonable to put things there first and then move them elsewhere when they are better defined and more stable.
Daniel Russel wrote: > I think I am still confused, is the experimental for any restraints > that deal with experimental data or for experimental restraints (i.e. > ones whose functionality is not yet completely nailed down)? If it is > the former, I misunderstood, but it should definitely have its tests > run. If the latter, it seems quite reasonably to run tests on it, but > not have the tests break the build. And it also seems reasonable to > put things there first and then move them elsewhere when they are > better defined and more stable.
It's the latter.
Ben
participants (2)
-
Ben Webb -
Daniel Russel