So, the commit in question as a diff comes out to about 4,200 lines: [email protected] s018 /tmp/k2/kafka> svn diff -cr1156232 | wc -l 4160
To me, regardless of how the diff was created, this disqualifies it from being a trivial change, particularly since it was done via automation, which tends to be the source of many unintended consequences. But of course, it's possible to make a huge change via a single line, so defining trivial just by size alone is not sufficient. For me, 'trivial' changes are one-line spelling fixes, quick commits to get the build compiling again due to a syntax error, or adding a single license header to a file. Re: reviewboard. Having done hundreds of patch reviews in Apache and now being required to use RB as a Hive contributor, I very much dislike it. It adds an extra level of paperwork to each patch, clutters the JIRA with impossible-to-trace comments from rb, and can inadvertently lead to the wrong patch being committed (see HIVE-2276 for an example). We've reached a happy medium in Hadoop where, those who would like a review via RB can open one a request, but it's not required and the reviewers are free to just post their comments within the JIRA itself. -Jakob On Wed, Aug 10, 2011 at 12:45 PM, Henry Saputra <[email protected]> wrote: > Hi Guys, > > I just got "pinged" by Jakob about the RTC =) > > I am not sure how strict we want to impose this rule? > > What considered as trivial changes? I guess if we want to strictly > impose this we should sign up to https://reviews.apache.org/ for Kafka > to help review the patch and diff. > > We use the reviews site for Apache Shindig and Gora. > > Thoughts? > > - Henry > > On Mon, Aug 1, 2011 at 4:26 PM, Jun Rao <[email protected]> wrote: >> Hi, Everyone, >> >> I propose that we use the "review then commit" process for future changes in >> Kafka. Other than trivial changes, all patches will be reviewed in JIRA. Any >> objections to this? >> >> Thanks, >> >> Jun >> >
