As Jun has also mentioned the concept of "trivial" is relative to each individual, unless we make it explicitly defined what considered trivial checkins.
I understand Hadoop project is good example to follow but this is not Hadoop project. I disagree to bring Hadoop way of doing project unless approved by Kafka community. IMHO Hadoop MapReduce or HBase projects are already in a stable phase where every checkin need to be scrutinized to make sure it wont cause any regression. Apache Kafka on the other hand is just still in podling incubator which could benefited from welcoming env in building community to help move it to TLP. Like you just said even Hive impose RB which Hadoop MapReduce or Pig may not. So every ASF project can and will have its own rules and policies. I just want to remnd that Apache Software Foundation is more than Hadoop project, and Kafka podling should have its own policy based on background and opinion from its community instead of 100% refer back to how Hadoop work. Now, I would love to move on and help getting Kafka ready for prime time. - Henry On Wed, Aug 10, 2011 at 2:40 PM, Jun Rao <[email protected]> wrote: > Hi, > > I agree with the list of trivial things that Jacob listed. > > For the license header change that Henry made, I probably would consider it > a trivial change. However, maybe it's a good idea to list the change to be > made in the jira first. > > Jun > > On Wed, Aug 10, 2011 at 2:28 PM, Henry Saputra <[email protected]>wrote: > >> Sounds good to me Jakob =) >> >> I think its just a matter of perception what considered as trivial. >> For me it was changes that wont make any behavior change. >> >> As for reviews site, I was not implying that it should be mandatory. >> It helps when reviewing large changes. LIke Jakob said, JIRA case is >> still needed and if he/she wants to use reviews site then it could >> added to JIRA. >> >> If "trivial" means size of changes, I am 100% support. >> >> - Henry >> >> On Wed, Aug 10, 2011 at 2:07 PM, Jakob Homan <[email protected]> wrote: >> > 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 >> >>> >> >> >> > >> >
