+1 to just using PRs. I think the benefits to new people to the project make it worth it to switch. New people will see PRs from committers when they are creating their PRs, which will help provide good examples. It's one less system to sign up on as a contributor so it's easier for new people to find and comment on committer PRs.
Personally I've switched from reviewboard to PRs and it works well for me. You can just mention people in comments to ask for a review. You can get your nice "queue" view, just go to https://github.com/pulls/mentioned to see all of the open PRs where you are mentioned. I agree it would help to have a convention to know if a PR is from a committer or not. So far I think we've just relied on the fact that the committers generally know who the other committers are. One thing that can help is if you add your github id to your apache profile - the PR will then show that it is coming from an apache member. -Dan On Thu, Jun 8, 2017 at 10:05 AM, Jacob Barrett <jbarr...@pivotal.io> wrote: > 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 don't see how PR complicates the process for committers since all work > should be on a topic branch and would be merged by the committer after > review (PR or Review Board). The process of merging the changes does not > change. > > > > 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. > > > > While PR doesn't have a nice queue concept it does allow you call out > individuals by mentioning them in comments. > > > > 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. > > > > Yes, I wish the PR system was not read only with ASF but having used this > proposed method extensively with geode-native I really find it not to have > a consistent single place to do reviews of bother peer committers and > contributors. > > Another argument for this proposal is that individual contributors don't > have to learn two different review methods to review committer's works nor > do they have to change review methods if they are voted in as committers. > > -Jake >
