On Mon, Feb 6, 2017 at 2:12 PM, Scott Brozell <sbrozell.rci.rutgers.edu>
wrote:
> Hi,
>
> Just to set the record straight, I was not referring to --skip-python.
> As i wrote in my post, an example is the commit regarding AMBERHOME;
> that commit added this to configure:
> export AMBERHOME=`pwd`
>
> Not testing this in an environment where AMBERHOME is undefined
> is like adding feature x to program y and then not testing the
> x y combination.
>
>
Just make thing clear: My comment in $AMBERHOME/configure about no need to
set AMBERHOME is actually mis-leading. I only meant that user do not need
to explicitly doing
export AMBERHOME=`pwd` before running ./configure. (Of course he/shell can
still do that).
but he/she still need to source amber.sh before "make install" (which also
setting AMBERHOME env).
So basically AMBERHOME is never been undefined at install time. (that's why
I have never tested this).
Hai
> scott
>
> ps
> those pretty sure about this or that can read the logs and become sure.
>
>
> On Mon, Feb 06, 2017 at 01:57:44PM -0500, Jason Swails wrote:
> > On Mon, Feb 6, 2017 at 12:29 PM, Scott Brozell <sbrozell.rci.rutgers.edu
> >
> > wrote:
> >
> > > 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).
>
>
> _______________________________________________
> 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 Mon Feb 06 2017 - 11:30:04 PST
