ReviewBoard is now the official review tool for juju

[Dimiter Naydenov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yeah, sorry I forgot the pastebin links to the scripts:

git-sync: http://paste.ubuntu.com/8352455/
git-propose: http://paste.ubuntu.com/8352460/
git config -l | grep alias: http://paste.ubuntu.com/8352470/
(useful aliases I use)

On 15.09.2014 21:54, Dimiter Naydenov wrote:
> 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-buday at 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.naydenov at canonical.com>
juju-core team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUFzccAAoJENzxV2TbLzHwKkgH/0f4/oc2uiuo/vgbvjVM0UWe
/0cF7MshfJV1dVRFZjBJV8EKuKNM0Z3DIJ6ypljJTRqn+osd3pv7svheqTD5ZE+k
JGjYZJ2HuZDgxeL/0yXLT+dWjKj/5dyZjTRKmQacASXMhO3siEoMVhK1kYoTDRNp
4lQtYWkxaLmlCxIobRWaGDQT2TwQ0ICIgicwXXYBqaAa197Gkbc/vbCOpVHJyxHM
HvKut28qen1HlWat9lvUcyrnA0337398p+f7gXWam/5Co9WIWiqtAw+At5ay2AIk
5n/0orPB9sGRqQzV8sYXTDosxkNe3WLFyoLkW2iMy1tnXrGBV3xuKq2yGke6+1c=
=bxal
-----END PGP SIGNATURE-----