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
Received on Wed Feb 24 2016 - 21:00:03 PST
