Ross,
what's be benefit of thinking AMBER as a whole package rather a suite of
difference packages?
why do we really need to centralize it? and why pain?
taking cpptraj as example (since people know it):
1. centralized AMBER: if people want to add code to cpptraj
+ clone amber repo
+ make a new branch, make code change, recompile, do a bunch of testings
with different combinations
+ merge to ambe master branch, push to remote
2. github: if people want to add code to cpptraj
+ clone cpptraj repo on github
+ make a new branch, make code change, push to github and let travis do all
the testing. No worry about old computer.
+ Dan will review code, merge code if he thinks ok
+ merge back to amber repo, push to remote.
The only difference I can think of is that package manager (Dan for
cpptraj) needs to approve the code change (which is good) + many advantages
using travis.
Note: If anyone does not like github, they can still edit cpptraj code in
amber repo (but not encouraged to do so).
Hai
On Wed, Feb 24, 2016 at 5:47 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
> >
> > I think AMBER only needs to make pmemd private repo (or I know at least
> > pytraj, cpptraj, parmed, pymsmt are public repos). Here is the price
> > https://github.com/pricing
> >
> > ($25/month for organization with 10 private repos)
>
> Yeah I saw that just now - although it's not clear how big those repos are
> allowed to be. Note what we really want is, I believe, a single repo called
> AMBER where parts of it are private and parts of it are public and
> depending on how one authenticates determines what parts you can see.
> Running it as two separate repos would be a pain I think and ideally we
> want to preserve the idea that AmberTools is the 'free' component of the
> overall AMBER software suite so if we want to open up the AmberTools part
> of the repo to public development we have to figure how to do this. Or we
> make components of this public - e.g. the cpptraj part, the pytraj part etc
> - for this we will need fine grain authentication methods and I don't know
> if GitHub supports that.
>
> <can_of_worms>BTW, this all works great until some gets scooped on
> something they did and made public while it was being developed. It will
> happen sooner or later - think we end up making force fields that are under
> development public etc etc...</can_of_worms>
> _______________________________________________
> 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 - 15:30:04 PST
