Re: [AMBER-Developers] Issues applying AMBER11 bugfix.all after extracting AMBERTools 1.5

From: David A. Case <case.biomaps.rutgers.edu>
Date: Sat, 21 May 2011 10:00:44 -0400

On Fri, May 20, 2011, Scott Brozell wrote:


> 2. any release of amber or ambertools should release both and
> reset the counter for bugfixes, etc; yes, this means that the
> release process must be changed so that the $$ code goes only
> to those that paid for it. this can also get us to sensible
> version numbers: 12.0 amber+AT, 12.1 amber12 + the next AT.
> ( and by the way, stop thinking in terms of amber and AT;
> there is only Amber: some of it costs $$. )

But this doesn't address our problem: when a new AT is ready for release, it's
no longer compatible with the "old" amber. If we update sander/pmemd along
with the new AT, it upsets our pricing scheme -- maybe that's not so bad, but
needs to be thought about.

> 5. this gives us an opportunity to undo this silly amber/AmberTools
> directory hierarchy: parts of amber cost money - if u pay
> then u get those parts, if u dont pay then u dont get them;

The (non-silly) reason for having the AmberTools directory structure is to
make it clear which parts of the code are covered by which license. I don't
see any way around this.

> why change the directory hierarchy? changing it was a developer
> implementation detail.
>
> > On Thu, May 19, 2011, Jason Swails wrote:
> > > option would be to sell *only* pmemd, as that program is entirely
> > > self-contained (one could argue except for NetCDF libs, but that's unchanged
> >
> > I think this is a good option, but there are probably lots of ramifications.
> > But we should seriously consider it for the next release. We would then make
> > an (internal) commitment to keep pmemd self-contained, so that the Amberxx
> > and AmberToolsxx are much less intertwined than at present.
>
> This idea looks good. And its easy to work into the above.

Well, in my mind, it's actually quite different than "the above": in this
scheme Amberxx (aka pmemd) and AmberTools become completely separated,
both in directory structure and release timetable. If (as an example)
we want QM/MM in pmemd, it would be a different, "mature" and only
slowly-changing version, presumably ported from sander, but separate from
it. The "fast" and wide-open development would continue in sander.

> Who's in charge of pmemd now ?

De facto, Ross. De jure, all of us.

...dac


_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat May 21 2011 - 07:30:02 PDT
Custom Search