[IMP-dev] Final message on reorganization

[Daniel Russel <>]

I don't feel that other people have really given serious thought to what 
various proposals for reorganization of the repository would entail and 
has included far to many wild assertions about what the outcomes of 
various changes would be. I don't know who else people think is involved 
in the project, but as far as I know, everyone involved is pretty 
reasonable, able to follow directions, can communicate over email and 
aware of their limitations.

There are three disparate issues to consider:
- the location of code in the svn repository: I propose that it be kept 
as simple as possible. The only advantage gained by splitting things 
into separate modules is a decrease in compilation time, which given the 
size of the swig files, might be worthwhile. Many modules means more 
things that have to be tested together, and makes it harder to reuse 
code and harder to discover new code. My favoured solution would be an 
IMP_kernel as discussed and an IMP_code which has all the current 
restraints and things (including domino and em).

- access control to the repository: we are all pretty reasonable, able 
to follow directions, can communicate over email and aware of our 
limitations, so I don't see any reason to impose access restrictions on 
anyone. As we saw in the last couple of days, adding layers of 
complication to submission increases the chance of bugs being introduced 
via the submission process. I haven't gone back and checked, but I am 
pretty sure Ben has broken the repository by changing patches more times 
than the number of bugs he has found by reviewing the code. In addition, 
with access control, we run into problems like when Ben was on vacation 
and Frido discovered a bug in the NonbondedLists and no one could commit 
a patch.

- how bits of code are designated stable or unstable: I suggest that 
this be through deoxygen groups. This makes it easy to move things from 
unstable to stable without break people's code (which would break if it 
involved changing modules). In addition, it ensures that, except in 
unusual cases, there is only one version of a particular class, reducing 
confusion.

All the setups which have been discussed would provide a set of clearly 
marked stable functionality which doesn't change much. So raising issues 
related to that is silly. In addition, conflating access to svn, the 
location of code and their stability simply confuses the discussion.

Something should be done about these decisions sooner rather than later, 
as there will only be more code that has to be updated later.

Anyway, I don't think I have anything more to say on the subject. I'm 
off with my brother the next couple of days. If a solution which allows 
me to reasonable commit changes to the code I contributed is not in 
place by Tuesday, I think I will give up on IMP and stop submitting patches.