-----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 >> <[email protected]> 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 <[email protected]> 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----- -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
