This one was a nice example: https://gerrit.cloudera.org/#/c/4186/
I think a good benchmark is that small patches like that should only take 1-2 review iterations once a contributor has the code style and process down. On Fri, Dec 9, 2016 at 11:34 AM, Jim Apple <[email protected]> wrote: > +1. Thanks for coming up with this idea and sending out this note, > Tim. I think this is the right move. > > On Fri, Dec 9, 2016 at 11:14 AM, Tim Armstrong <[email protected]> > wrote: > > Hi All, > > I just wanted to follow up on the previous emails about starting the > code > > review process for your Impala patches. We'd really like the process to > go > > as smoothly as possible > > > > One thing we really need to figure out is how we might test and maintain > > PPC code. We only really have access to x86 build infra and it isn't > > feasible for us to maintain PPC code that we can't test. It's a burden on > > contributors who want to touch the code and gain confidence they're not > > breaking anything, and also on PPC devs who will likely get accidentally > > broken repeatedly. > > > > I'm also concerned making sure that the code review process goes as > > smoothly as possible, since each iteration can take a lot of time, > > especially if we're working across different time zones. We have a fairly > > high bar for code quality and maintainability, and in our experience it > > takes a bit of time for contributors to calibrate for that and post code > > reviews that can get through the process smoothly. > > > > I'd suggest that you should identify some small platform-agnostic fixes > in > > your patchsets and start off with posting code reviews for those. That > way > > we can make progress and get you ramped up on the code review process > > before we've resolved the more difficult PPC testing questions. > > > > https://cwiki.apache.org/confluence/display/IMPALA/ > Contributing+to+Impala > > is our main reference for the process. > > > > Thanks, > > Tim >
