On Thu, Nov 24, 2011 at 9:37 AM, Mark Williamson <mjw.mjw.name> wrote:
> On 11/23/11 14:31, David A Case wrote:
>
> 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.
>
This is generally agreed upon and the current situation will not be
repeated.
> 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.
>
I actually disagree here a little. I agree that patches should remain
ASCII (or compressed ASCII for large patches), but I think I wrote a script
that will make patches much easier. I've posted about it in the (recent)
past to this list and it automates the process of checking for,
downloading, applying, and tracking applied bug fixes.
http://dev-archive.ambermd.org/201111/0087.html I'm still waiting for
feedback if you want to give it a go ;)
2) Ensure a bugfix is a bugfix. Refrain from using the bugfixes as a
> conduit for new features.
>
The feature enhancements were pmemd.cuda, and were the result of external
pressures to release new functionality. This is the desired path, but it's
not always possible.
3) Move any code that is susceptible to large feature changes into
> the
> AMBERTools branch which has a more frequent release cycle.
>
pmemd.cuda doesn't belong in AmberTools and would kind of defeat the
purpose of the division in the first place. In any case, we're going to
rethink the release strategy, I think.
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.
>
There's a page on the Wiki
http://ambermd.org/pmwiki regarding bugfix
creation where this whole process is outlined. I agree with you that this
is important (and one of the most significant barriers to building our
user-base), and I've given a lot of attention (and words on this list) to
this exact issue.
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 Thu Nov 24 2011 - 08:00:04 PST
