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

[Friedrich Foerster <>]

some opinion from far away:
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. that always worked well for years in modeller and nobody  
seemed to have the same problems as daniel. maya, madhu, eswar, marc,  
even min-yi, and whoever i forgot were fine with that solution. with  
our em stuff and all functions for the 26s it works reasonably well  
that way as well.
from keren's and mine experience in working on the same depository i  
know that it can easily happen that even two people revert each  
other's changes and other things. if people even have somewhat  
different opinions on certain things disaster is bound to happen, i  
think. for example, non-functional svn versions will annoy everybody  
and IMP would die rather quickly. of course, svns can be reverted, but  
everybody loses time. 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...
so what speaks against the solution to put many functions into modules  
where the authorship and responsibility is clear? 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 ;) 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.

cheers

frido




--

Friedrich Foerster
Max-Planck Institut fuer Biochemie
Am Klopferspitz 18
D-82152 Martinsried

Tel: +49 89 8578 2651



www.tomotronic.org




On Aug 20, 2008, at 7:15 PM, Daniel Russel wrote:

> The current IMP rcs setup is completely idiotic. As a result, in order
> to be able to actually track the changes I make to the IMP kernel I  
> have
> to maintain my own fork and then move patches back to the main svn.  
> I am
> tired of doing this and am somewhat inclined just to maintain my own
> (public) fork and forget about contributing back to the main IMP  
> svn. As
> there are occasionally a few global changes, reconciling things will  
> get
> increasingly hard over time.
>
>
> Restricting who can commit to svn offers no benefits over open  
> submissions.
> - code review as it now stands appears to simply consist of checking
> formatting of the source files. Such can changes can be more easily  
> done
> as a modification of already checked in code. That would have the  
> added
> advantage of not having svn report everything as a conflict (svn gets
> confused by my changes being committed from another working copy).
>
> - No one is counting on IMP svn being constantly in a working state.
> People wait to check things out until they know they have some time to
> clean things up. As a result, there the invariant that all versions of
> the repository work doesn't buy us anything over ensuring that it  
> works
> almost all of the time. The latter would make it easier to submit
> patches since you don't have to ensure all files are submitted at once
> and you can more easily check that your patch is OK by checking IMP  
> out
> and building it. Unless the automatic test scripts for IMP are a  
> mess it
> should be easy enough to have them create a "last stable" branch in  
> svn
> upon successful completion of the tests.
>
> - svn is a revision control system. It allows us to roll back  
> changes we
> don't like after they are committed. That is the point.
>
> And the current system has many disadvantages:
> - submitting patches takes a reasonable amount of effort. As a result
> minor changes to documentation and things which result in IMP overall
> being a nicer experience never get submitted. In addition, it makes
> people wait longer to submit things making the eventually submission
> that much more complicated and reviewing of changes that much more  
> involved.
>
> - since it can take days (sometimes weeks if Ben is away) to get even
> the simplest patches committed, it takes a lot of work to make focused
> patches. Our time is better spent elsewhere.
>
> - IMP is supposed to be a collaborative effort. It is hard enough to  
> get
> people to share their code without added hurdles. As it is, I seem  
> to be
> the only one inclined to go through the effort.
>
> - we can't actually use svn as a revision control system. If  
> everything
> in in sync most of the time, then once can easily try speculative
> changes and then revert them if they don't work. Since I can't do  
> this,
> I have to maintain my own svn repository with a copy of IMP.
>
> - we don't have any easy record of who last changed each file without
> reading the whole log making it harder to know who to ask about  
> changes
> and breakages.
>
>
> Creating yet another project in IMP svn doesn't solve these problems  
> and
> results in another complication for people who want to use IMP since
> they always have to think about which library to get it from/which
> namespace to use.
> _______________________________________________
> IMP-dev mailing list
>
> https://salilab.org/mailman/listinfo/imp-dev