ReviewBoard is now the official review tool for juju
Nate Finch
nate.finch at canonical.com
Mon Sep 15 14:56:52 UTC 2014
Really, rbt pull -p is the only new step. All the rest of that is stuff
you should already be doing as a normal part of writing code and making
pull requests. I guess adding the link on the PR to the review is also a
new step. If you really want to count that as a step.
On Mon, Sep 15, 2014 at 10:50 AM, Eric Snow <eric.snow at canonical.com> wrote:
> On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow <eric.snow at canonical.com>
> wrote:
> > Yeah, those steps are a lot, though keep in mind that effectively it's
> > only 2 steps more than before if you use the -p flag to rbt post and
> > were already keeping your local master up to date.
>
> Just to be clear, here are the steps again, slightly reformatted:
>
> (0). Rebase relative to upstream master.
> - if origin is different than upstream, sync and push it
> 1. Create a pull request via github.
> 2. Run "rbt pull -p" while at your branch to create a review request.
> 3. add a comment to the PR with a link to the review request.
> 4. address reviews until you get a "Ship It!" (like normal, with LGTM).
> 5. add a $$merge$$ comment to the PR (like normal).
> 6. mark the review request as submitted.
>
> So, steps 2, 3, and 6 are completely new. They don't add a lot of
> work and I plan on automating all 3 of those new steps.
>
> Step (0) is also pretty easy and I'll argue that people should be
> doing it anyway.
>
> -eric
>
> --
> 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/20140915/58005e29/attachment.html>
More information about the Juju-dev
mailing list