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.s...@canonical.com> wrote: > On Mon, Sep 15, 2014 at 8:09 AM, Eric Snow <eric.s...@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@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju-dev >
-- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
