On Fri, May 01, 2015 at 11:09:14AM -0700, Stephen Hemminger wrote: > With email, the patches are right in front of developers and easier to quote > for review comments.
Right in front of that subset of developers who do everything kernel-style, perhaps yes. But this sort of workflow is in the minority these days, pretty much every other project I've worked on besides the kernel used graphical merging tools for this to make things easier to follow for the uninitiated. The GH pull requests are more friendly to all the non-kernel-style developers we're saying in these threads that we are hoping to get more involved in DPDK. I use DPDK on purpose because I don't want the ultimate purpose of my application to be getting into the middle of huge hard-to-read hard-to-follow threads, core-kernel flamewars, hard-to-read weird 30-year-old network stack code, panics that take down my machine instead of debuggable core dump files, etc. So I'm hoping we could get a patch review system that's more modernized. Something where anybody can easily read and quickly the patches without a bunch of email-client-specific headaches, and a sea of emails to be saved off and fed into git apply-patch, and branches ready-to-go for checkout for testing, review, and repatching if they have mistakes in them. Having the branches published centrally enables a modernized DevOps style workflow, where I can grab a new branch, run some kind of Integration Test of the feature or even just experiments with it in my own code, and go back to the central place to report how it worked, what was right and what wasn't, even better, I can send along a PR to the PR branch, with more stuff it needs before it's safe to place into master. Matthew.
