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.