When a project gets really large, there are many reasons it can be simpler to have subprojects. I don't think this is divisive at all. I think it helps keep sanity.
The main page makes it plain that the individual projects are all sub-projects of Amber-MD (
https://github.com/Amber-MD):
Amber Molecular Dynamics
For experienced Amber users: development versions of some parts of AmberTools
That sounds great to me. More advertising, if anything. To me, these are subtrees. Well... and they are in fact, as well. :-) But, I suppose you want something a little more automated than that. I agree that such a thing would be useful.
I think the subprojects might also help attract potential developers. It might seem intimidating - and possibly unnecessary - for someone to become an Amber Developer if they just want to add a little tweak to cpptraj/etc. I would probably be more likely to contribute if I were a relative stranger if I could interact with a smaller piece. And, if I got really into it, then you'd know you had someone you should entice into the fold.
Regarding squashing... if there are over 1000 commits per year to the main GH repo for something, then I might see if it would be better to have more local developer squashes. That is, I agree with not squashing between the satellite repo and the main AMBER tree. Instead, I would try to do squashing at the developer level when possible. I'm guilty of not squashing when I should: I'm pretty sure that most folks don't want to read a commit every time I change a few characters in a file.
:-) Lachele
Dr. B. Lachele Foley
Associate Research Scientist
Complex Carbohydrate Research Center
The University of Georgia
Athens, GA USA
lfoley.uga.edu
http://glycam.org
________________________________________
From: Ross Walker <ross.rosswalker.co.uk>
Sent: Wednesday, February 24, 2016 11:30 PM
To: AMBER Developers Mailing List
Subject: Re: [AMBER-Developers] git logs and squashing commits
I'm sold on the github idea - you don't have to convince me here. Although I do have concerns over the long term viability of github as a service provider especially the long term economics of the continuous integration. Note I am also not convinced that enforcing the escrow will solve everything since it doesn't fix the competing deadlines / overworked issue, it would likely just mean a lot less new things at the time of release and a lot more stuff pushed into updates after release.
What I am not sold on is the current individual project approach. This is what we all need to discuss and agree on. People moving their individual project onto github was not the correct way to do this. This should have been done in consultation with the rest of the development team and implemented in a coordinated fashion.
How to do this in a way that presents a more coherent front and the perception of a team development effort on a single project (AMBER) and can survive the loss of individual developers from that team without their respective code withering and dying from neglect is what we need to address. We should not be a bunch of individuals working in silos here. Yes the AMBER test suite is a mess - we should all be pitching in here to help improve this so we can make use of CI properly - the 'not my problem, not my code' argument doesn't fly if you want to be associated with AMBER - simple as that. We all share responsibility here.
Conceptually what I feel like we need - and am fully open to discussion of this in a few weeks in person - is a single git repository (github is fine given the positive arguments) for AMBER - part of that would be private for the licensed code and part would be public (with some restrictions to protect novel things from public view that people might not want to [or are not permitted] to disclose before publication) and then within this git tree would be a series of 'sub-trees' for each of the various packages (and maybe an etc for minor scripts etc) that one could clone / check out independent of the whole AMBER tree if they wanted to help with parmed for example.
Obviously I know this is not supported by github but we ought to be able to figure out a way to put something together, with necessary scripts etc that at least approximates something like this - and potentially this might mean having better github like software on our own servers or something else or relying on a third party provider such as github or ??? - that can effectively give us something that looks like this framework.
Discussion / ideas welcome.
All the best
Ross
> On Feb 24, 2016, at 19:50, Jason Swails <jason.swails.gmail.com> wrote:
>
> On Wed, Feb 24, 2016 at 10:41 PM, Ross Walker <ross.rosswalker.co.uk> wrote:
>
>>
>>> On Feb 24, 2016, at 19:32, Hai Nguyen <nhai.qn.gmail.com> wrote:
>>>
>>> On Wed, Feb 24, 2016 at 8:11 PM, Ross Walker <ross.rosswalker.co.uk>
>> wrote:
>>>
>>>>
>>>> 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.
>>>
>>>
>>> I don't think the human nature is good excuse. It's developer
>>> responsibility.
>>
>> Agreed - but it happens every time so clearly is something systemic in
>> nature.
>>
>
> ​Sounds like a clearly stated need for a system that does not merge changes
> into the master branch until CI reports a successful build. The reason
> GitHub works here where our system doesn't is because GH effectively holds
> commits in escrow before making final payment. If the payment is
> validated, it clears into the main account. If not, it sits in escrow
> until it's fixed, and doesn't pollute the master branch that others may be
> depending on.
>
> CI doesn't work nearly as well when it doesn't stop you from making changes
> to the upstream repository that don't pass the tests. That's why
> CruiseControl -- as cool as it was -- wasn't a game-changer the way
> Travis-CI is. And GH has hooks to host our own testbot (via Jenkins) if
> Travis's resource limitations are too severe for our uses.
>
> See, with the GH system, we don't *have* to all be software engineers to
> employ solid SE practices. That's the whole point. The fact that we're
> *not* all software engineers makes it all that much more important to do
> something like this.
>
> All the best,
> Jason
>
> --
> Jason M. Swails
> BioMaPS,
> Rutgers University
> Postdoctoral Researcher
> _______________________________________________
> 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
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Wed Feb 24 2016 - 21:30:04 PST
