So, the automation between github and reviewboard seems necessary, so we should do that. It shouldn't be hard at all. Then the steps for submitting code will be:
1.) Submit a PR 2.) Get it reviewed on the automatically-created review. 3.) With a LGTM on the review, mark as $$merge$$ and the bot merges it. 4.) There is no step 4. Note that this is the exactly the same steps if the review is on github or reviewboard. Then we can just address the pros and cons of each without worrying about the impact on workflow. Github pros: - Comfortable for people who only know github. - Slightly more "visible" since the reviews happen right on github. Reviewboard pros: - Far less email spam. - Better handling of updated code mid-review. - Supports chained reviews. - Customizable. Let me know if I missed anything, but this still seems like Reviewboard is the way to go. And yes, let's please continue to trial it until we can discuss in Brussels. We can always trivially switch back to github if/when we want to. On Mon, Sep 22, 2014 at 11:05 AM, Eric Snow <eric.s...@canonical.com> wrote: > On Sat, Sep 20, 2014 at 12:01 AM, Jesse Meek <jesse.m...@canonical.com> > wrote: > > On 20/09/14 02:34, Eric Snow wrote: > > I was not seriously suggesting we return to lp. Using ReviewBoard > > reintroduces what we gave up with lp: both the good (tooling that > addresses > > pain points) and the bad (not a well known/widely adopted process of > > contributing). In this regard, using ReviewBoard is akin to returning to > lp. > > Sorry, I misread. Thanks for clarifying. > > > > > It is not a question of "does ReviewBoard address our pain points" nor > is it > > a question of "is this just teething?". Both valid questions in their own > > right, but they miss the point. Is raising the bar to outside > contributors > > necessary and justified? > > What do you mean by raising the bar? If you mean the extra steps > we've introduced for reviewboard, I agree to the extent that we do not > yet have any automation between github and reviewboard, and we must > take the steps manually. However, once we have automated those steps > it will be a non-issue. > > Furthermore, I will argue that reviewboard provides a better code > review experience than github. That's a relatively subjective > assessment, but there are also concrete benefits that I hope I've > outlined well in the "pros and cons" thread. > > FWIW, I do not plan on updating the CONTRIBUTING doc until after we > have github-reviewboard automation in place. Until then outside > contributers won't have to worry about reviewboard. And afterward > they still won't have to worry about more than simply following the > link to the review request for their PR. > > > > > Is it necessary? Many of us have addressed our own pain points with > GitHub > > already. I use browser plugins, git hooks and scripts to augment my > > workflow. > > I'd be interested to know what folks are using to work around the > deficiencies in github (reviews or otherwise). I expect such things > would be generally useful. Ideally no one would need to worry about > such workarounds, which is what we're trying to address via > reviewboard, but I expect that any such tools would be useful, > reviewboard or not. > > > Yet I can work along side the first time contributor that has > > nothing more than git and a GitHub account. What pain point necessitates > > raising the bar to contributors? > > I agree that, without the github-reviewboard automation, any > requirements to use reviewboard are more roadblocks to contribution. > > > > > Is it justified? Given such a pain point exists, does solving it justify > > *forcing* a new tool on a developer? This is the decision we are making > and > > it is not just for 'us' the team. It is for our would-be external > > contributors. The ones that we moved to GitHub for. > > I'm glad you spoke up on this. It's important we keep this firmly in > mind when making any changes to workflow. FYI, I had a patch for > CONTRIBUTING.md that updated the workflow relative to the new > reviewboard steps/tooling. However, you've convinced me to abandon it > in favor of simply waiting until we have automation in place, to avoid > adding barriers to entry. Thanks. :) > > -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
