Friedrich Foerster wrote: > what is all the fuzz about? i thought ben already proposed a neat > solution in that not everything needs to be in the kernel. anyway, imp > was meant to be modular, i thought. so whatever does not need to be in > the kernel should not be there and in a different module instead. in > that module everybody can mess around as he wishes, at least to some > extent.
Indeed. This is exactly what I proposed, but perhaps more succinctly put. All sorts of things rely on the kernel interfaces being stable, and the lab culture is to use current SVN for everything, so code changes there should go through code review, which thus far means me. The kernel was always envisioned to be compact; almost everything else belongs in a module. (If nothing else, this prevents the SWIG wrappers from becoming monstrous.) This could be remotely hosted (e.g. a lab outside of UCSF, or in a different SVN repository in the lab, as is currently done for Assembler) or it could be in IMP SVN (as is done for domino and impEM). Modules need not be subject to the same scrutiny - for example, Keren has write access to the domino and impEM modules. She does not need to send me patches, chat on the mailing list, undergo code review, etc. - although typically she is responsible and sends any changes by me first for review. Each module has an owner (Keren in this case) who works with me to set whatever policies they think are sensible. For impEM, so far this has meant I continue to review changes, since Keren was happy with that. For Assembler, Keren and Frido have essentially equal access. One could also envision a restrainer module owned by Jeremy, or an npc_dynamics module owned by Daniel, for example.
For experimental stuff that doesn't neatly fit into an existing module, I could certainly create an 'unstable' module if there's interest. Essentially everybody would have write access to this module. Code review and test cases are still strongly recommended, of course, but failures of the test cases would not result in the nightly builds failing. So users would use the 'unstable' module at their own risk.
As per Keren's suggestion, stuff from 'unstable' that users start to rely on can be moved to a more specialized module, or to the kernel after code review. (One could even imagine having both an unstable and a stable form of a given feature, although I'd like to minimize that if possible.)
To avoid confusion and namespace clashes, I propose that a module 'foo' has its C++ code live in the IMP::foo namespace, C++ headers in IMP/foo/ (or IMP/foo.h if the module provides a convenience 'everything' header), and Python classes in the IMP.foo module. So the existing IMPEM Python module would become IMP.em and move from the IMP namespace to IMP::em. This also fits in nicely with existing Python-only modules such as IMP.modeller_intf (ideally would be IMP.modeller, but until we can require Python 3.0 or later, we're stuck with relative imports). And if users wonder why their code keeps breaking, it should be obvious from looking at either C++ or Python code whether they're using 'unstable'.
Ben