On Mon, Feb 6, 2017 at 12:29 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> Hi,
>
> I second the request for continuous integration, but testing before
> pushing is always necessary.
>
> If you are working in the master branch and change the behavior with
> respect to a global variable, eg, AMBERHOME, then you must install and
> test all of Amber (and with respect to a recent commit that automatically
> sets AMBERHOME, you must do it twice: both with and without an externally
> defined AMBERHOME).
>
Testing much beyond your own setup is so prohibitively time-consuming and
convoluted that the only testing that is really reasonable to expect from
people is to test on their own machine, *maybe* with two sets of compilers
if they happen to have ifort installed. If you have a CI infrastructure
(which I'm working in my spare time on setting up) you catch things like
forgetting to add a file to git (which isn't caught in your local
workstation where the files exist, but just are not tracked), and you can
use tools like vagrant and docker to set up corner-case environments and
build options to make sure that these corner cases are handled
automatically.
I'm pretty sure Hai *did* test his commits, and discouraging any pushes to
master that don't pass a wide array of corner-case tests is a recipe for
slowing development to a crawl (and to someone like Hai and me, not having
an up-to-date and robust Python installation is a corner-case).
In my opinion, this is an example of a problem that, realistically, will
only be caught by a comprehensive continuous integration setup with modern
dev-ops processes (like pull requests and code reviews and a policy of not
merging code that does not pass CI tests enforced at the software level).
All the best,
Jason
--
Jason M. Swails
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon Feb 06 2017 - 11:00:03 PST
