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:
http://bugzilla.ambermd.org/show_bug.cgi?id=158
Leaving this aside, I want to address a more fundamental point that this
highlights:
The combination of two (AT15_Amber11.py, 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.
Thanks,
Mark
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Thu Nov 24 2011 - 07:00:02 PST
