Re: [IMP-dev] One final attempt to stir discussion before I give up on IMP svn

[Daniel Russel <>]

First some summary comments:
- I am glad to see people actually posting to imp-dev :-)

- it seems like the two main directions to go are either
  - separate modules for things. If we go that route, Ben should  
remove the decorators, restraints and score states etc. from IMP svn  
and I'll package things up nicely in my svn repository. While it is  
not my favorite solution, it would be better than the current  
situation as the kernel would then be very compact and it will be easy  
to make patches for it.

  - more open svn where people have to learn how to play nicely with  
one another :-)

> for example, non-functional svn versions will annoy everybody
> and IMP would die rather quickly.
Yes, if it is non-functional frequently. I don't see that is likely  
under any plan. In my experience at various companies, everyone breaks  
svn once, gets bitched at and then knows to be careful for the rest of  
their lives. Part of the training process we are supposed to be  
undergoing :-)

Your usage seems to be typical so far: you update svn once every few  
weeks. As a result, it make no difference to you if svn does not  
compile for 5 minutes while some is committing patches.

> if IMP is meant to be employed by outside users,
> there needs to be a single responsible person whom you bug with emails
> etc if something goes wrong. that person obviously needs to know the
> code...
This I disagree with. We are much better off with a set of people all  
of whom know what is going on and feel responsible. With a single  
person in charge other people don't feel they have to pay attention  
and zone out until their they update svn and their stuff breaks from  
issues that were posted months before.

In addition, we have serious problems if the person in charge leaves  
or their interests shift as often happens in academics.

> so what speaks against the solution to put many functions into modules
> where the authorship and responsibility is clear?
It doesn't add any benefit over having just having one open svn  
repository
- svn tags each file with the name of the last person who committed so  
you always know who made changes and so who is responsible. It is also  
customary to label files with the primary author in the comments at  
the start if that is appropriate.
- separate modules means you have to remember more information for  
each restraint you use to know where the include is located or which  
python module to find it in
- separate modules results in less uniform interfaces since people  
don't feel as obliged to stick to relevant standards (this is not  
necessarily the case, but seems to be true in the projects I have  
worked on)

> for example,
> specific experimental restraints can go in there. with embed that
> works nicely. anyways, some people might prefer different solutions
> for specific experimental restraints and keeping it modular allows for
> that ;)
Nothing prevents people from keeping experimental things outside. I  
have lots of code that is separate from the IMP core. What we are  
talking about is things that are believed to be of common interest.  
And the more shared and easily accessible code, the easier it is for  
all of us.

> also different decorators and representations could go into
> modules. concerning the kernel, we all hope that it will be stable one
> day and API-changes are not very frequent.
It will stabilize (and has stabilized). But ultimately, it doesn't  
matter where the code that changed in is if you use it-- your code has  
to change either way.