Re: [AMBER-Developers] AMBER11 bugfix #19 is broken

From: Mark Williamson <>
Date: Thu, 24 Nov 2011 14:37:36 +0000

On 11/23/11 14:31, David A Case wrote:

> I suggest just updating bugfix.19 in place, but we could make a bugfix.20 if
> people think it is cleaner. I really hope we can limp home until Amber12,
> when things get cleaned up and we no longer have enormous feature enhancements
> disguised as bugfixes.
> ....dac

I wish I'd been able to reply into this thread a bit earlier; apologies.
There is a second issue here and in the interest of preventing the dev
mailing list from becoming a bugzilla, I've posted it here:

Leaving this aside, I want to address a more fundamental point that this

The combination of two (, apply_bugfix.x ) bespoke
scripts (in two different languages) to apply such a disruptive set of
changes to the release source, results in a patching mechanism that is
convoluted, fragile and error prone.

The current path is not sustainable; I am struggling to carry out some
of the most basic tasks when it comes to preparing/compiling AMBER and
regard myself as having above average experience with the codebase/OS. I
have no idea how a typical user on the main list is going to fare with
this; not too well I suspect.

I'm having to carry out constant rewrites to our internal AMBER
compilation documentation (for the students in the group), because I
find that it has suddenly been obsoleted with the latest bugfix release
(read paradigm shift). I want to be using the finite time I have to be
fixing real bugs and not fighting to actually get to the starting blocks.

Some ideas to fix this include:

        1) Ensure the bugfix is simple enough to be applied solely with the
patch command from an ASCII diff file. AVOID any scripts for the
application of the patches.

        2) Ensure a bugfix is a bugfix. Refrain from using the bugfixes as a
conduit for new features.

        3) Move any code that is susceptible to large feature changes into the
AMBERTools branch which has a more frequent release cycle.

        4) Automate bugfix generation. Branch the master to AMBER-X at release
time and then commit each bugfix monotonically to this branch. Generate
a patch by diffing the head of this branch to the current state of
that branch.


AMBER-Developers mailing list
Received on Thu Nov 24 2011 - 07:00:02 PST
Custom Search