Hi Jun,

No problem, I am glad to help any way I can =)

+1 for using our best judgement.

- Henry

On Thu, Aug 11, 2011 at 7:38 AM, Jun Rao <[email protected]> wrote:
> Henry,
>
> Yes, the definition of "trivial" is subjective. Personally, I think we
> should just apply our best judgement. If unsure, it's better to have the
> patch reviewed first. At the minimum, any trivial change should not break
> compilation and unit tests.
>
> Thanks for volunteering to fix the header in all files. I appreciate it.
>
> Jun
>
> On Wed, Aug 10, 2011 at 11:55 PM, Henry Saputra 
> <[email protected]>wrote:
>
>> 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
>> >> >>>
>> >> >>
>> >> >
>> >>
>> >
>>
>

Reply via email to