We are having some problems with our internal network right now so
unfortunately the cruise control dashboard is inaccessible. I'm trying to
get it up and will send another email when it's fixed.
Robin
On Tue, May 28, 2013 at 6:25 PM, Jason Swails <jason.swails.gmail.com>wrote:
> On Tue, May 28, 2013 at 5:46 PM, Daniel Roe <daniel.r.roe.gmail.com>
> wrote:
>
> > Hi,
> >
> > On Tue, May 28, 2013 at 3:26 PM, <dcerutti.rci.rutgers.edu> wrote:
> > > This is why I
> > > added the idea that each commit trigger one GNU compilation only, for
> > > serial and parallel builds. This, I think, will catch 90% of the
> > problems
> >
> > But developers should be doing this anyway before committing (as well
> > as running the tests), especially with GNU compilers since everyone
> > has access to them. Then the dashboard can catch other issues (like if
> > the compile breaks with a compiler you don't have access to). One
> > thing I like to do when I've made relatively large changes is I have a
> > separate GIT directory (i.e. separate from the one I commit from) that
> > I will update after I've made my changes and compile/test from there;
> > this catches things that don't necessarily show up in the other
> > directory (like if I forgot to 'git add' a file).
> >
>
> FWIW, I have a similar setup. One tree that is my 'working' branch and
> another that is typically clean (via `git clean -fxd') so I can test from a
> completely clean slate for large changes.
>
> These repos are connected to one another, and I can push/pull between the
> two repositories (on the same hard drive).
>
> We don't really have that many developers pushing into a single
> project/program right now (nowhere near 80 for any individual program). As
> long as people run the necessary test cases* and are responsive when
> informed that their commit broke something on another platform, I don't
> really have legitimate complaints about the status quo (plus CC). I'm
> guessing the inconvenience and setup overhead of any automated solution
> will outweigh the inconvenience of the occasionally incomplete commit. And
> as always, part of the glory of git is that all mistakes are reversible.
>
> --Jason
>
>
>
> *necessary being the key adjective here. Given the weight of the full test
> suite, I sympathize running a targeted few to evaluate the affect of a
> 'small' change to a single program. If you take many shortcuts you'll
> eventually be bitten by not running the full suite (we can all attest to
> that, I'm sure), but it's unreasonable to require all commits to be
> flawless in a project the size of Amber.
>
> To quote the Zen of Python:
> ...
> Now is better than never.
> Although never is often better than *right* now.
> ...
>
>
> > -Dan
> >
> > --
> > -------------------------
> > Daniel R. Roe, PhD
> > Department of Medicinal Chemistry
> > University of Utah
> > 30 South 2000 East, Room 201
> > Salt Lake City, UT 84112-5820
> > http://home.chpc.utah.edu/~cheatham/
> > (801) 587-9652
> > (801) 585-9119 (Fax)
> >
> > _______________________________________________
> > AMBER-Developers mailing list
> > AMBER-Developers.ambermd.org
> > http://lists.ambermd.org/mailman/listinfo/amber-developers
> >
>
>
>
> --
> Jason M. Swails
> Quantum Theory Project,
> University of Florida
> Ph.D. Candidate
> 352-392-4032
> _______________________________________________
> 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 Wed May 29 2013 - 16:00:02 PDT
