Reviewing in progress work on Github

[Jonathan Aquilina]

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
>