Hi Dan,
I think this thread is getting a little confused between advantages / disadvantages of github etc / squashing commits / comments etc vs the argument I am trying to make which is my concerns over AMBER being a brand / product / team effort. So I'll state at the beginning here.
I am agnostic to what method we actually choose here as long as we choose something that works well for everyone. My primary concern here is with the potential fragmentation and dilution of the concept of AMBER as a brand that I believe we are getting from having a bunch of projects on github. You can replace github with "I created my own repository and website..." and the underlying concern that I have does not change. This is what I think we need to first discuss at the AMBER meeting and decide how we should deal with it (do enough of us actually care?) and then with whatever constraints we come up with for this we should then discuss the pros and cons of various different solutions. We should then pick one and then depending on whether we decide if we need constraints to keep the AMBER brand together there should be a requirement (or not) that everyone use the new method if they wish to be part of the AMBER development team.
>> 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.
I think the real issue here is one of human nature. At the end of the day very few of us actually do the necessary work until we hit the deadline. It's not clear how github will magically fix that. We'd probably just end up hacking our way around the above due to time constraints. But I agree we need a way better testing procedure for code. The CI testing in github sounds very attractive but it is unclear to me how this can scale. That is an incredibly expensive feature to offer and I'd be surprised if it stays this way in the future. It's fine right now since the economy is doing well and there is lots of VC funding sloshing around. If things change and that dries up you'll see these incredibly expensive to run features disappear I bet.
Will it even allow us to scale to the entire AMBER test suite - if we divide things up with proper dependencies?
Again though - the main discussion we need to have is one of what it means to be part of the AMBER code base and the AMBER development team. The rest is just semantics and process optimization.
All the best
Ross
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 17:30:03 PST
