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.