Reviewing in progress work on Github

[John Meinel]

We looked at Travis CI, but it has a fundamental issue that Travis people
feel they don't want to fix. Which is that by default it only tests the
branch, without concern for what is on Trunk. Which you can fix in your own
hook, by merging trunk before running the test suite. However, it also
doesn't run the test suite again when Trunk changes, which means you can't
actually be sure that the test suite will pass when it is finally merged.
e.g.: If I change an API to take another parameter, and then fix up all
callers to pass a default parameter there, my test suite passes. If you
write a function that starts calling that API before I change it, your test
suite passes. If either of our code is merged without resolving the other
one, the test suite will break because there is a caller that isn't passing
the new parameter. So you do need to run the test suite at the time of
merging if you actually want the security of "the test suite has passed on
all revisions that land on master".

Travis CI would give a nice level of "everything looks good so far, go
ahead and try to merge". But we still need the final bot to run the tests,
so we started there. I would imagine it would be easier to update that bot
to do "would this be good if I merged it right now". And it could go
through the backlog as it has free CPU. The nice thing about Travis is that
they donate a *lot* of CPU to do your testing for you.
As a very quick pass, just having the 'test' compile the whole source code
would actually be fast to do, and still be a reasonably useful test.

John
=:->



On Thu, Jun 5, 2014 at 10:07 AM, Jonathan Aquilina <jaquilina at eagleeyet.net>
wrote:

> Not trying to hijack this thread, but a suggestion for reviewing and CI
> testing. I have a hunch you guys already have something in place, but
> there is TRAVIS CI which integrates nicely with github repos through a
> yaml file.
>
> When a pull request is submitted it performs a build and then on the pull
> requests lets you know if the build was successful with that change or
> not.
>
> Apologies if this derails the topic, but in terms of reviewing it might be
> helpful.
>
> > You can keep updating a pull request as your work on a feature. Old diffs
> > and comment are preserved. On nice feature is that old comments are
> hidden
> > if the area of the code they reference is changed by a later diff.
> >
> > This link from the Github people themselves is light on detail but talks
> > about how they use a pull request as a way of tracking work in progress
> > right from the beginning of the development of a feature.
> >
> > https://github.com/blog/1124-how-we-use-pull-requests-to-build-github
> >
> > I guess this doesn't address the email spam problem but it does seem like
> > it would work otherwise. People can individually opt out of notifications
> > about a specific PR but that's not really ideal.
> >
> >
> >
> >
> > On 5 June 2014 15:41, Ian Booth <ian.booth at canonical.com> wrote:
> >
> >> You can, but then you loose any previous comments and history on the
> >> previously
> >> work in progress pull request. With Launchpad, you could just flip the
> >> status on
> >> the merge proposal and all the comments would be retained.
> >>
> >> On 05/06/14 13:38, John Meinel wrote:
> >> > Can't you just create a new Pull request when it is finally ready?
> >> >
> >> > John
> >> > =:->
> >> >
> >> >
> >> >
> >> > On Thu, Jun 5, 2014 at 7:25 AM, Ian Booth <ian.booth at canonical.com>
> >> wrote:
> >> >
> >> >> One of the many things I miss now that we have moved to Github/git is
> >> the
> >> >> ability to put up a merge proposal with in-progress work, allowing
> >> >> collaboration
> >> >> on the implementation as it evolves etc. Launchpad supported this
> >> nicely,
> >> >> as it
> >> >> didn't spam people with emails for wip mps etc.
> >> >>
> >> >> I don't think Github supports this concept. Perhaps a way around it
> >> is
> >> to
> >> >> do a
> >> >> pull request against one's forked copy of the main Juju repo. That
> >> way,
> >> >> people
> >> >> can still easily see your work, but without the general spam. Sadly,
> >> it
> >> >> doesn't
> >> >> allow the pull request to then be re-targetted to the Juju repo when
> >> ready
> >> >> to be
> >> >> reviewed for real. Or does it?
> >> >>
> >> >> Does anyone have any better ideas how to do this?
> >> >>
> >> >> --
> >> >> Juju-dev mailing list
> >> >> Juju-dev at lists.ubuntu.com
> >> >> Modify settings or unsubscribe at:
> >> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >> >>
> >> >
> >>
> >> --
> >> Juju-dev mailing list
> >> Juju-dev at lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >>
> > --
> > Juju-dev mailing list
> > Juju-dev at lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
>
>
>
> --
> Juju-dev mailing list
> Juju-dev at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-dev/attachments/20140605/801337bc/attachment-0001.html>