I recommend we proceed with GitHub integration as implemented by Apache, and reassess the strengths/weaknesses of that approach after a period of time to see whether it makes sense to make improvements, keep it as is, or scrap the approach. Additional comments are below.
On Wed, Feb 19, 2014 at 2:16 PM, Tim St Clair <[email protected]> wrote: > Maybe it simply becomes a bootstrapping mechanism to > accept simple patches, and direct them to the full process. > +1. There are tons of patches that are small and receive a #shipit with no or minimal comments; I see these as particularly good candidates for pull requests. > I think a clever scripter(or bot) could probably convert a pull request > into a > ReviewBoard submission, and possibly send a link back on the pull-request. > Possibly, I'm inclined to first give the existing solution a try and see whether this is necessary. > There is still the definite blocker that committers cannot close pull > > requests: > > https://github.com/apache/mesos/pulls > I assume the script handles this, but I haven't reviewed it myself and I may be incorrect. cc'ing Jake Farrell, who may know. > benh: Having pull requests become ReviewBoard reviews seems a little odd. > > The author will need to learn how to use ReviewBoard to continue the > > process, unless there is some two-way review update mechanism (which > sounds > > way too complex). I would imagine this would create more headache for the > > author of the patch. > I agree. > > A downside of having two places for reviews is that we now have to look > at > > both Github and ReviewBoard to get the full story. Outsiders to the > project > > can easily look at one of these and think they're seeing the full picture > > if they don't look at the mailing list. Probably not a blocker but it is > > pretty unfortunate. > Most contributions including bug fixes should have JIRA issues associated with them anyway, so I don't see this as an issue for outsiders of the project. > > I would be ok with reviewing small patches on Github for those getting > > their feet wet, but ultimately I would agree that a single source for > > significant reviews would be great. There are still some inherent issues > > with GitHub reviews that make it difficult to review large patches (no > > side-by-side diffs, 1 email per comment). > Agreed. In cases with larger or substantial patches I think it's fair to ask folks to move their reviews over to review board. > To play the devil's advocate: Why not use Github 'issues' as well? Why do > > we ask folks to create reviews when they upload a .patch file to JIRA, > why > > not review the .patch directly in JIRA? The answer is we don't want two > > issue trackers, three review systems, as there is added project > management > > overhead. > I appreciate you playing devil's advocate, but in this case I don't think these concerns are valid. JIRA isn't a suitable tool for review because it lacks basic in-line commenting of patches that are necessary for feedback/review; both ReviewBoard and GitHub include this feature although they differ in their complexity. We should look at this less as a question about project management (needing to control a single process for how the community does work), and instead look at is as a question about what tools provide the best experience/use for the job. For many smaller patches, GitHub provides the best experience for developers and makes no difference to reviewers who will give a simple #shipit. And for larger patches, ReviewBoard provides the best experience for reviewers, forcing developers who may be unfamiliar with RB to learn the ropes (and they've likely crossed that hurdle of investment where they will put in the time to do so). Both tools have different uses, and are useful to different audiences. Let's not worry about either displacing the other, and instead embrace these differences by adopting both tools. Best, Dave
