On Nov 26, 2011, at 9:35 PM, Ross Walker wrote:
> Hi All,
>
>> I think all we need is a cuda cruise control build for amber11-with-
>> patches,
>> which would have caught this problem. [We currently only test the
>> serial
>> version of amber11-with-patches.]
>
> Ok, I setup Cruise Control to also do the CUDA serial and parallel builds
> for amber11-with-patches. Of course this does NOT work because the
> amber11-with-patches tag is for AMBER Tools 1.4 with AMBER 11+patches which
> of course uses an incompatible configure script. Suggestions? We can't have
> Cruise Control test building CUDA for amber11-with-patches since this is an
> invalidated build target since AT1.4 is no longer compatible with AMBER11.
> Thus I think we need amber11-with-patches updated to be AMBER 11 + Patches +
> AT15 + Patches since this is what we are effectively releasing and is what
> needs to be tested.
True, amber11-with-patches will not work for testing anymore. I don't think we need to set up cruise control for Amber11 + Patches + AT 15, just don't repeat my bugfix.19 mistake. I did not test the CUDA portions (only), which was foolish since it was a CUDA bug fix; yet more evidence that assumptions are dangerous.
> Any ideas how we do this? - Just apply all the git commits from
> AT1.4+bugfixes until AT1.5 release and then the AT1.5 bugfixes to the
> amber11-with-patches branch?
This will *definitely* not work. That will bring the Amber portions up to the Amber snapshot at the point when AmberTools 1.5 was released, which, as far as the user community knows, never existed at all. The only 2 ways I can see this working is
1) Delete all AmberTools source code and other AT files from a (completely clean) git repository checked out at amber11-with-patches and unpack an AmberTools 1.5 tarball on top of it, apply all of the patches, and then add that all in as a commit. (This is similar to how I "unrolled" sqm back to version 1.4 for the AT 1.5 release.)
2) Just unpack a fresh AT15 + Amber11 into a fresh directory, apply all bug fixes, and create a whole new repository from that.
The first allows us to piggyback off of our existing repo without creating the weight of a second. However, it's more error-prone. Furthermore, the practice of using amber11-with-patches was _not_ well-adopted at the outset. I added the first 2 bug fixes by hand to that branch when I generated patches 18 and 19 (which I noticed since patch 18 only succeeded at an offset on a fresh checkout). Thus, I'm not confident that we can trust the state of amber11-with-patches, which makes 1) an even less attractive option.
IMO, if we simply _must_ have an at15-amber11-with-patches branch, I suggest we use a whole new repository and do it that way (2). If that's something that we're interested in, then I will create that repo if a gitosis admin will give me the rights.
Sorry, this has turned into a bit of a rant.
All the best,
Jason
--
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
Received on Sat Nov 26 2011 - 21:30:03 PST
