-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Eric,
On 15.09.2014 21:18, Eric Snow wrote: > On Mon, Sep 15, 2014 at 11:05 AM, Katherine Cox-Buday > <katherine.cox-bu...@canonical.com> wrote: >> Let me preface this by saying I like the Reviewboard style of >> reviewing changes. >> >> It's somewhat concerning to me that our reviews are now >> disconnected from what will actually be landed into trunk. In >> Github, you were reviewing the actual diff which would be landed. >> In reviewboard, we're now reviewing a diff manually uploaded by >> the developer. There's a lot of room for error in terms of what >> diff we review vs. what diff we land. >> >> Any thoughts on how to couple these things once again? > > I'm working on integration between github and reviewboard such > that creation of a PR creates a new review request automatically. > The same goes for updating a PR. Not only will that address what > you are talking about, it will remove the extra steps of > creating/updating the review request yourself and of closing a > review request as submitted. Ergo, rbt would not be needed for the > typical workflow. You would still use it for "pipedlined" > branches, though that could probably be automated as well. - From my meager experience with writing git plugins (any executable in $PATH with "git-" prefix), what are you describing can be easily achieved. If you write a git plugin, named e.g. "git-rbpropose", using the GitHub CLI (https://github.com/github/hub) and rbt, you can automate the process: 1. Pushing the branch to origin (checking for uncommitted changes). 2. Creating a GitHub PR for the branch, which includes launching the default editor to fill-in the PR description (using hub). 3. Creating a RB review (using rbt). 4. Optionally opening the default browser with it. I have a couple of handy scripts that do this, which I've shared before: git-sync (), and git-propose (), along with a few aliases (). git-sync fits especially well with the RB workflow, because it pull upstream/master into your local repo's master, then pushes it back to origin/master, and finally (when you're on a branch other than master) rebases all branch commits over origin/master, interactively. What usually do is run "git propose" after the finaly "git sync" to create a PR - the only thing missing is the RB steps. > There is the possibility of pushing info from ReviewBoard back to > github (e.g. "ship-it" -> "LGTM" comment), but I don't think it > buys us enough to make it worth it (it's notably trickier). > > -eric > Cheers and thanks for all the hard work around putting RB workflow in place, - -- Dimiter Naydenov <dimiter.nayde...@canonical.com> juju-core team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUFzXyAAoJENzxV2TbLzHwPT8H/jeke5kS/VoNxL/mmGaK4IWW 5+tS7VNH9DewaRj4ZPsLtKmQvHW5oXYf5aJFEXpC3LFD9vqkyyNJQwoOaoBOQnwh FkDmTOALgXYYBd7PPsXI3fjUhjfKdcug8y7SmLLyvS61APHV1yH5++hyJdsHUany 80kFVkTbkXoMRW7BtdHREgH/tDdnEaHgJpQzbUPEuk/+gd82+q4+lnbvfs8sR/00 x1OGXzdiyGjwKSgbeFyEfUD0+mIG8xI7IUx1oVTLoLYM82i6WGZOB6g3qnh3s/bK 0ylyy09q645SNyDgsuZp8Bt8VrG92K057M/O/O+QnkeDkSHuqb27hKS+wFO2Ekg= =mfDJ -----END PGP SIGNATURE----- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
