Ross,
I totally agree that we benefit each other from citation for AMBER brand. I
just have few points here
1. I don't think we need to bring all packages in AmberTools to github. Not
all of them need heavy development (for example: tleap, nab, ...). We are
bring cpptraj, pytraj, ParmEd ... to github to satisfy our need in
development (pytraj have 5000 commits in a year). I am pleased with current
model (infrequent commits programs are still developed in amber repo while
frequent (mostly everyday) commits should move to github to utilize the
continuous testing).
2. Per citation, I don't see any issue. General users only care about
download AmberTools or AMBER at once, do compiling and use different
packages. They just don't care about github or even know what github is.
They just try to download AMBER (or AmberTools) at once, to installing and
use all packages in AMBER (vs they need to git pull individual pieces from
github and do the installation by them self). In my opinion, a package with
easy installation + less bug + more user supports will get more attention.
For example, Anaconda (or Miniconda) Python distribution from Continuum
made millions of downloads every year because they make the installation +
glue packages very well.
There are many competitors with AMBER, especially GROMACS (6509 citations
for Gromacs 4,
https://scholar.google.co.jp/scholar?oi=bibs&hl=en&cites=208462507478232993).
Recently Gromacs has GPU implementation too. So, we need to introduce more
features, more integration with 3rd party packages (such as right now we
has sander Python interface (by Jason) to integrate with big community like
Phenix, Rosetta, ...). What's we need (for heavy development packages) is
great environment like github and travis.
In summary, my point is let amber repo as it is right now, we only need to
bring pytraj, cpptraj, parmed, or any active packge to github. Nothing to
lose (since it's free) but getting more functionality, more reliable
software.
Hai
On Wed, Feb 24, 2016 at 8:11 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> 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
>
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 19:30:03 PST
