On Mon, Feb 23, 2015 at 1:02 AM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> On Sun, Feb 22, 2015 at 09:23:51PM -0500, Jason Swails wrote:
> > > On Feb 22, 2015, at 5:17 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
> wrote:
> > > On Sun, Feb 22, 2015 at 12:45:05AM -0500, Jason Swails wrote:
> > >>> On Feb 21, 2015, at 10:52 AM, David A Case <case.biomaps.rutgers.edu>
> wrote:
> > >>> On Sat, Feb 21, 2015, Gerald Monard wrote:
> > >>>> No odd numbers anymore. It also leaves some
> > >>>> time (until the '16 release) to re-factor the directories and
> decide if
> > >>>> we drop the AmberTools naming.
> > >>>
> > >>> A couple of points along this thread:
> > >>>
> > >>> 1. We can't merge the AmberTools and Amber source trees together.
> The
> > >>> split between the AmberTools stuff and the pmemd stuff is there
> because
> > >>> they fall under different licenses. Intermingling the trees would
> just
> > >>> confuse that issue.
> > >
> > > This does not make sense. pmemd has its own source directory and
> license
> > > file as do some other programs (and as ~every program once did before
> > > Dave rearranged things years ago):
> > > src/pmemd/src/copyright.i
> >
> > > AmberTools/src/cpptraj/LICENSE
> > > AmberTools/src/reduce/LICENSE
> >
> > > Please provide a syllogism that explains the split.
> >
> > See below.
>
> Where, i did not see it ?
>
> What i saw was the statement
> "The current directory split was VERY convenient when I designed
> update_amber ... "
>
> I want to see the logical proof that licensing forces us into the split.
> Or an admission that no such proof exists and thus that we could
> theoretically merge.
>
This isn't about, and has never been about, *forcing*. But apparently
since everyone is licensing their own code the way they want in AmberTools,
the split gives no clarity on this front. I'll probably punt this question
to Dave.
However, right now update_amber needs the split; the split is very useful
to update_amber and is central to many of the things that allow
update_amber to keep things simple for users and developers and
safe/informative against mistakes. So to me, the split is entirely about
updating convenience so the install/update process can be equally simple
for people that have and haven't purchased pmemd.
Justifying the split 6 years ago can't be done in a way that everyone will
agree "that had to happen" (everyone didn't agree 6 years ago). But that's
not what's on the table now. The change that's being proposed is merging,
and I'd like to see justification of why we need to merge that makes the
work needed to redesign update_amber justified (assuming that I might not
be around to do, fix, or maintain it).
All the best,
Jason
--
Jason M. Swails
BioMaPS,
Rutgers University
Postdoctoral Researcher
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 23 2015 - 03:30:02 PST
