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.orghttps://salilab.org/mailman/listinfo/imp-dev
