On Feb 11, 2011, at 9:34 AM, case <case.biomaps.rutgers.edu> wrote:
> On Fri, Feb 11, 2011, Mark Williamson wrote:
>
>> At this moment in time, the amber11 branch has lost sync with the
>> published bugfixes;
>
> Here's my suggestions:
>
> 1. get rid of the existing amber11 branch; I don't think anyone is using it
> (but speak up!) and it is not reliable for its original intended usage.
I did use it occasionally (whenever I needed Amber 11 to check something). It presents a very easy method to create and disseminate bug fixes without having to worry about applying all of the ones before it. It's too bad it hasn't been kept in sync with the patches. I'm also of the opinion that bug fixes are few and far enough between that it should be easy enough to keep the two in sync (just have a very explicit protocol about how they should be made). Perhaps I'm being a bit too naive here.
>
> 2. if people need to see what users have (e.g. for debugging problem reports)
> they should do this:
>
> check out the "v_11" tag from git (presumably into a clean directory);
> apply the bugfixes from the web page
The bug fixes are very large for single files (uncompressed) and may take a while to download on some poor connections. This is an annoyance easily avoided on the amber11 branch.
>
> 3. When AmberTools 1.5 is released, we will tag that. (That tag will also
> include whatever is on the master branch for amber itself as well, but I don't
> see that as a major problem: if you are interested only in AmberTools, just
> ignore the rest.
I see no issue here
>
> 4. Someone could use the procedure in item 2 above to recreate an
> amber11-with-patches branch. The periodically repeat it to keep it up to
> date. (We should not go back to the current, error-prone method of manually
> applying changes to the amber11 branch -- changes there should always come
> directly from the web page, so we can be certain that the branch and the web
> page are in sync.) But personally, I am not sure the gain is worth the effort
> to do this.
I would be fine with this. The sync could also be achieved with deriving all fixes with git diff, as long as we can get all bug fixers to bother with the protocol in the first place.
>
> Comments are welcome; thanks to Mark and Scott for looking into this.
If we were to do away with the amber11 branch I would probably just create my own. Just my own 2c
>
> ...dac
>
> --
>
> ================================================================
> David A. Case | email:
> BioMaPS Institute and Dept. of | case.biomaps.rutgers.edu
> Chemistry & Chemical Biology | fax: +1-732-445-5958
> Rutgers University | phone: +1-732-445-5885
> 610 Taylor Rd. |
> Piscataway, NJ 08854-8087 USA | http://casegroup.rutgers.edu
> ================================================================
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Sat Feb 12 2011 - 06:30:02 PST
