+1 to Bruce's comments. PRs are for contributors that do not have commit privileges. ReviewBoard is a tool for "reviewing" changes.
However, what is also common practice on open source projects, even for committers, is to create a topic branch containing the commit with the desired changes (labeled with an appropriate JIRA ticket + description). Then a reviewer can then pick up the topic branch, review the code changes, polish things up and even merge the topic branch back into the mainline (e.g. develop) and close the ticket. IDEs, more than ReviewBoard/FishEye, etc, have better tooling for reviewing diffs, making change, running tests, etc. -John On Thu, Jun 8, 2017 at 8:32 AM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > One thing I find confusing in PRs is whether the person submitting the > request is a committer or not. Non-committers need someone to merge the PR > while committers are just looking for a review and will merge the changes > to develop themselves. > > I also don't see any way to push a PR to specific individuals for review. > In Reviewboard there is a nice queue of pending reviews that I can go > through. On github they're all mixed together and it's difficult to tell > whether any of them are relevant to me. > > I like the idea of a single source of history for reviews but I don't much > like the idea of having to create PRs on a read-only system and then merge > my changes to ASF's repo. Being able to commit directly seems like a > committer perk that your idea would take away from us. > > > On 6/7/17 6:42 PM, Jacob Barrett wrote: > >> All, >> >> I would like to discuss transitioning all code reviews to pull requests >> over using review board. For non-committer community members we ask them >> to >> make pull requests against the mirrored GitHub repo. Some committers use >> pull requests for their own work reviews while others use review board. I >> propose that we just use on and that the one we use be pull requests. It >> would give us a single source of history for reviews, a single model to >> understand for reviewers and committers and keep workflow consistent with >> all contributors, committers or not. >> >> -Jake >> >> > -- -John john.blum10101 (skype)
