On Wed, Feb 24, 2016, Jason Swails wrote:
>
> git submodules can help with that -- that is *precisely* for managing a
> superstructure that is composed of git repos (so that git knows where to go
> off and clone all of its components). What I'd like to see is each
> component in a separate repo with only pmemd on our own servers, all
> enveloped within the Amber-MD GitHub organization. Code reviews, proper
> issue tracking, ...
Sounds good to me, but how do we get there from where we are? Could we
generate a submodule framework on github.com/amber-md with what is there now,
then slowly add more programs?
About testing before commits to a master branch: we have never had a set of
tests for (say) sander that all PASS on more than about one platform. And
it's not just laziness -- there are some real difficulties involved for
chaotic MD simulations. Even cpptraj shows a number of test failures on my
machines, just to illustrate the difficulties involved here. travis-CI is not
a magic bullet.
Finally, we should keep in mind that there can be a downside to making it more
onerous to complete a commit: people will continue to work in their own
branches, and we don't get as much effective testing because fewer people are
using the code. Just saying that the test cases pass is generally not
enough--having the code actually being used a lot in real world applications
is also needed. We've had plenty of cases where code gets committed to meet a
release deadline, and passes tests, but has unidentified flaws or limitations
because it has only been used by one or two people, and on a very limited
number of applications.
(I know I'm contributing to what is already a long-winded conversation; but I
think this is good, since there won't be time in March to go over all these
issues...)
...dac
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Feb 25 2016 - 05:30:03 PST
