>> I think we may be saying the same thing. I am differentiating between regular contributors (who are likely committers) and first-time contributors.
Agree with this. Once the review tool is stabilized and reviewed, will update the patch workflow wiki to reflect this distinction. Thanks, Neha On Thu, Sep 12, 2013 at 12:43 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > I think we may be saying the same thing. I am differentiating between > regular contributors (who are likely committers) and first-time > contributors. > > What I am saying is that if I had made some small change to a piece of open > source software and they asked me to install some new software to give them > the patch I would probably not bother to do that. The argument that if I > did do it it might be lower friction over the long run could be true but it > basically doesn't matter...I'm not going to bother learning their custom > thing to find out. I feel the same way about any project using mecurial or > bazaar--these may be superior tools but the burden of learning esoteric > stuff just to contribute to one project isn't worth it. I really think the > right thing to do is to require as little as possible from first-time > contributors and do the leg work ourselves. If they later end up doing a > bigger project we can ask them to switch to the better tooling. > > -Jay > > > On Thu, Sep 12, 2013 at 10:16 AM, Neha Narkhede <neha.narkh...@gmail.com > >wrote: > > > Thanks for the feedback. > > > > This tool is actually designed to reduce the review overhead and make > > reviews less time consuming and more readable. So this is more of a > > contributor's workflow than a committer's workflow. I agree that this > might > > be too much of a process to follow for one-time smallish contributions to > > Kafka. In such cases, just creating a JIRA and attaching a patch might be > > easier. But for more active contributors or for big patches, this 10 > minute > > setup will actually end up saving time for all the committers/reviewers > > since big patches typically involve several patch revisions and > re-reviews. > > > > To improve the usability of the tool, we should reduce the setup time as > > much as possible, maybe even package up the tool with the codebase so it > > requires almost no setup. > > > > Thanks, > > Neha > > > > > > On Wed, Sep 11, 2013 at 8:11 PM, Jay Kreps <jay.kr...@gmail.com> wrote: > > > > > I think this is awesome! > > > > > > Two quick things: > > > > > > 1. I think once we have vetted review board and this tool it would be > > good > > > to consolidate the committer workflow documentation. Currently we have > a > > > git workflow, a review board workflow and a review tool workflow. I > > > actually do not have the ability to remember any more commands, and > have > > to > > > jump between projects with different tools, so I refer to these kinds > of > > > things a lot. > > > > > > 2. I don't think this is very good for people trying to make first-time > > > contributions to Kafka. We already have a fair amount of rigamarole > from > > > Apache with creating JIRAs and uploading patches vs the github workflow > > > people prefer. The git workflow outlines a contributor and committer > > > workflow and I think we should retain that distinction and just > recommend > > > the extra tooling to committers. > > > > > > -Jay > > > > > > > > > > > > > > > On Wed, Sep 11, 2013 at 5:55 PM, Neha Narkhede < > neha.narkh...@gmail.com > > > >wrote: > > > > > > > Hi, > > > > > > > > I'm proposing a new patch review process that will save time on code > > > > reviews and make the patch review process easier, with a one time > setup > > > > cost. > > > > > > > > I wrote a tool that will do 2 things - > > > > > > > > 1. Create a patch and upload it to an existing JIRA > > > > 2. Create/update reviewboard with the same patch and link it back to > > the > > > > JIRA > > > > 3. Update JIRA with a comment that points to the reviewboard > > > > > > > > To use this tool, you will need to go through a one-time setup cost > of > > > > installing jira command line tools and reviewboard tools. The setup > as > > > well > > > > as usage is documented here > > > > < > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool > > > > > > > > > > > > > I've created a rb <https://reviews.apache.org/r/14091/> as well as > > > created > > > > a JIRA <https://issues.apache.org/jira/browse/KAFKA-1053> for this > > (yes, > > > > using the tool :)) > > > > > > > > So the proposed patch review process is - > > > > > > > > 1. Create a JIRA > > > > 2. Make code changes and commit to local branch > > > > 3. Use the patch review > > > > tool< > > > > > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool > > > > >that > > > > will update the JIRA with the patch and create/update the > > > > corresponding reviewboard > > > > > > > > Will be great if people can give this a spin and provide feedback on > > the > > > > new patch review process. > > > > > > > > Thanks, > > > > Neha > > > > > > > > > >
