Daniel, I understand your points and indeed you are the main contributor to IMP and a very experience software engineer. Maybe your case should be an exception, but in general I completely agree with Ben's policy. Ben's policy assures that IMP is basically working. We can not trust changes made by anyone and even in big software companies ( such as google), every change should go through a code review process. IMP is being used by various people, some without formal CS background and some are more flexible and tolerant than others. If we do not want to loose those users and if we want to make IMP a reliable software - I believe that we should maintain the current policy. I guess that you might be a special case as you are the main contributor - but for others we should keep the current policy. Just an example, today Frido and I, for our 26S project, updated IMP and than it took us at least an hour to solve all of the broken interfaces. This happens a lot and some people might give up on IMP or just use an old version and never update ( Frank's MODELLER 3 in restrainer is an extreme case for that).
An alternative might be to manage nightly builds (for developers) as well as weekly/biweekly ones (for users). In the nightly builds IMP developers could submit their code and the weekly ones the users can rely on stable code. Code will move from the nightly to the weekly only after testcases have been written and passed a code review process. what do you think? also - I attach a comic on code review ( dedicated to Minyi :) )
best, Keren.
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 > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
