Hi All,
I have one quick thought about this and it relates to
something I do with RNAstructure development.
I would vote for option 1, separate Amber and AmberTools
repositories, which Dave gave the con of:
"Considerable code duplication: sqm, pbsa, rism, lib (others?) would
be present in both releases."
One way to avoid code duplication is for Amber-* to
explicitly depend on code in AmberTools-*. This makes sense because
AmberTools is freely available, so it is unlikely that one would have
Amber without AmberTools.
This would depend on users and developers having the code
trees adjacent in their directory structure, so the dependencies can
be resolved. It would also mean that developers would need to do a
cvs update in both sandboxes to keep things synchronized. There
would also be some details to work out in specifying exact
dependencies if the two repositories had version numbers in the
directory names. In my opinion, this is much better than allowing
code duplication, which will certainly be very confusing.
Another possible option 3 is switching to SVN, which I
understand is much better at handling changes to directories. One
could then have a single repository in SVN that would have Amber and
AmberTools side-by-side. As versions of each change, new directory
names would be placed in the SVN repository.
Sincerely,
Dave
At 09:22 AM 1/30/2010, you wrote:
>At the developers' meeting, there were various suggestions for how to
>handle the Amber/AmberTools split. This is a request for comments for some
>ideas along this line.
>
>Option 1:
> unpack Amber into a tree headed at Amber-11.0/
> unpack AmberTools into a tree headed at AmberTools-2.0/
>
> Each would be a full and separate package. Users would set AMBERHOME
> to the AmberTools-2.0 location, since Amber codes don't use such a
> variable. Users would put both Amber-11.0/bin and AmberTools-2.0/bin
> in their PATH.
>
> Amber users would still need AmberTools, as in a package dependency.
>
>Pros:
> Simple to explain to users. We could upgrade AmberTools without
> worrying about Amber. Amber tests and AmberTools tests would be
> cleanly separated.
>
> Having versioned directory names is more in line with gnu/linux software
> practices.
>
> We could support different compilers/OS's in AmberTools than in Amber;
> the configure script and config.h file would not be required to be the
> same. For example, we would probably not need to support pgcc for
> AmberTools.
>
>Cons:
> Considerable code duplication: sqm, pbsa, rism, lib (others?) would
> be present in both releases. Bug fixes would have to be made in two
> places, using different patch files as the two codes diverge. If we
> indeed have AmberTools releases not coordinated with Amber releases,
> then we have the awkward situation that the functionality and results
> for the same calculation (e.g. QM) are different in the two codes.
> If we truly separate the two parts, we would need massive documentation
> duplication as well as code duplication.
>
> Hard for developers, since the tree that users would see is different
> from the one we are developing on. (This is probably a minor concern.)
>
> Psychologically, we weaken the perception that AmberTools is a "genuine
> part of Amber". (This might be a rather important drawback; or maybe
> not.)
>
>Option 2:
> Continue with the current model: both codes unpack into an amber11
> tree, which AMBERHOME points to. We make sure that any updates to
> AmberTools (either through bugfixes or an intermediate release) remain
> compatible with Amber -- no more "jumping ahead" to a new directory
> tree as we did with AmberTools-1.3.
>
>Pros:
> Doesn't have the "cons" of Option 1.
>
>Cons:
> Doesn't have the "pros" of option 1. Might be quite difficult to meet
> the requirement that changes in AmberTools have to "work" inside the same
> tree as Amber itself. Hard to keep licensing terms clear when code with
> very different licenses reside inside the same tree.
>
>Option 3:
> Something different from the two listed above.
>
>Comments? I'd like to get this figured out soon, since attempts to clean
>up the installation (e.g. merge src/Makefile with src/Makefile_at) depend
>on what we decide.
>
>Please think hard about the branding and perception issues -- the other things
>are mostly technical that we can probably solve.
>
>....thx....dac
>
>_______________________________________________
>AMBER-Developers mailing list
>AMBER-Developers.ambermd.org
>http://lists.ambermd.org/mailman/listinfo/amber-developers
___________________________________________________
David Mathews, MD, PhD
Assistant Professor of Biochemistry & Biophysics
and of Biostatistics & Computational Biology
University of Rochester Medical Center
Room 3-6830
601 Elmwood Avenue, Box 712
Rochester, New York 14642
http://rna.urmc.rochester.edu
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 08:30:03 PST
