Hi everyone:
IMHO there is no time left for separation for this release.
Otherwise, apart from branding issues, this is certainly a
good idea.
With kind regards,
Volodymyr
On Sat, January 30, 2010 09:22, case 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Jan 30 2010 - 09:00:02 PST
