Hi,
On Wed, Feb 24, 2016 at 4:14 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> The key then is are the all the nice features GitHub offers - integration testing etc - worth us paying for the service? Or having our own servers (which also come with a cost but a somewhat hidden one) but running some kind of better software than the simple Linux distro with Gitosis and ssh that we have right now?
This is really the key for me - in my opinion the development model on
GitHub (pull requests + CI testing) is far superior to what we have
been doing with Amber. On Amber development goes something like this:
1. Pull from Amber master, create local repo
2. Create branch
3. Make changes on branch.
4. Run tests
5. Merge to local master.
6. Push to Amber master
The problem is that steps 2-4 are not enforced (people often make
changes directly to master which can be bad), and I'm not sure there
is any way to enforce them, particularly step 4. This is how we end up
with broken code/tests just days before the code deadline. Step 4 is
also really hard even when you try to do it - there are a lot of
different build types (serial, MPI, openmp, cuda, cuda MPI), not to
mention the different combos of compilers/parallel libraries that
there are. Also certain test suites (like the sander serial tests)
take *ages* even with a fast setup. It was nice when Cruise Control
was up and running builds, but even then you only caught a broken
build *after* the fact, when it was already broken for everyone.
On GitHub development goes like this:
1. Create a fork from the main repo
2. Create a branch on your local fork
3. Make changes on branch
4. Generate a pull request for your branch to be merged back into the main repo.
5. CI kicks in and tests the changes on a variety of platforms
(cpptraj currently tests linux gcc serial/openmp/mpi, clang serial,
and windows mingw compile). If the tests fail you go back to step 3.
6. If the tests in step 5 pass, you merge into the main repo, then
pull back into your local fork.
This model ensures that the code in the main repo is always passing
all the tests you give it.
>
> Whatever we ultimately decide we should at the very least find a way to automate things here - ideally in both directions - on a per commit basis so we don't force people to have to go use GitHub and close a certain repo instead of a centralized AMBER one.
One of the reasons I mentioned GitLab as a possible alternative is
that you can control the servers and it has all of these nice features
(I think - I actually have not worked with it yet). Certainly changing
the current development model is something to consider going forward
given that the size and complexity of the code will just keep
increasing.
-Dan
>
> Maybe a good summer project for a comp sci REU person?
>
> All the best
> Ross
>
> /\
> \/
> |\oss Walker
>
> ---------------------------------------------------------
> | Associate Research Professor |
> | San Diego Supercomputer Center |
> | Adjunct Associate Professor |
> | Dept. of Chemistry and Biochemistry |
> | University of California San Diego |
> | NVIDIA Fellow |
> | http://www.rosswalker.co.uk | http://www.wmd-lab.org |
> | Tel: +1 858 822 0854 | EMail:- ross.rosswalker.co.uk |
> ---------------------------------------------------------
>
> Note: Electronic Mail is not secure, has no guarantee of delivery, may not be read every day, and should not be used for urgent or sensitive issues.
>
>
> _______________________________________________
> AMBER-Developers mailing list
> AMBER-Developers.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber-developers
--
-------------------------
Daniel R. Roe, PhD
Department of Medicinal Chemistry
University of Utah
30 South 2000 East, Room 307
Salt Lake City, UT 84112-5820
http://home.chpc.utah.edu/~cheatham/
(801) 587-9652
(801) 585-6208 (Fax)
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 16:30:04 PST
