Re: [AMBER-Developers] git logs and squashing commits

From: Jason Swails <>
Date: Wed, 24 Feb 2016 22:50:41 -0500

On Wed, Feb 24, 2016 at 10:41 PM, Ross Walker <> wrote:

> > On Feb 24, 2016, at 19:32, Hai Nguyen <> wrote:
> >
> > On Wed, Feb 24, 2016 at 8:11 PM, Ross Walker <>
> 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 M. Swails
Rutgers University
Postdoctoral Researcher
AMBER-Developers mailing list
Received on Wed Feb 24 2016 - 20:00:06 PST
Custom Search