Re: [AMBER-Developers] bug fix protocol

From: Scott Brozell <>
Date: Sat, 5 Nov 2011 01:54:57 -0400


Gee can't we all just write bug free software;
./apply_bugfixes.x --downdate-tree
to undo broken bugfixes



ps seems like a good idea at least in the absence of those pesky details
btw r u running for political office :)

On Sat, Nov 05, 2011 at 01:26:38AM -0400, Jason Swails wrote:
> I'll take a break from my long-winded (and poorly-thought out/worded) posts
> to propose a new method for bug fixes, without unimportant implementation
> details. Feedback is appreciated (flag and program names are certainly not
> fixed, just the basic ideas).
> I suggest that we include a program/script with every Amber/AmberTools
> release, let's call it "patch_amber.x". This program will automate and
> completely handle the process of downloading and applying bugfixes for any
> AmberTools/Amber distribution we have, regardless of how we package them
> (each AMBERHOME directory will have 1 smart script that figures out what to
> do based on what packages are present).
> It can be used to determine what bug fixes have already been applied
> ./apply_bugfixes.x --patch-level
> returns a list of the bug fixes that have been applied.
> ./apply_bugfixes.x --check-updates
> Looks up on the website to see if there are any *new* bug fixes that have
> not been applied, and gives the user details about what bug fixes are out
> there and what they do/patch.
> ./apply_bugfixes.x --update-tree
> Goes onto the Amber server, downloads the bug fixes that have *not* yet
> been applied, applies them (telling the user what it's doing along the
> way), and then instructs the user to recompile.
> ./apply_bugfixes.x --download-patches
> Same as --update-tree, but doesn't actually apply those patches. Think one
> ring to rule them all ;).

AMBER-Developers mailing list
Received on Fri Nov 04 2011 - 23:00:07 PDT
Custom Search