[DISCUSS] patch review process

[Hyunsik Choi <hy...@apache.org>]

Hi folks,

As the community and the number of contributors grow, more patches are
being submitted. We have faced the increasing burden of patch peer
review. So far,  we have mostly submitted patches to Jira and leaved
comments on the corresponding JIRA issue. This way is not bad, but its
productivity for review is not good.

In order to mitigate the burden of patch review, I propose that we
should use reviewboard for more significant than minor issues.
Reviewboard allows reviewers to directly add ideas and comments on the
diff or source code. In addition, Reviewboard enables reviews to view
the only difference between two patches. I think that they are really
nice features. I believe we will experience more efficient and
convenient review process if we use reviewboard more. I also think
that this rule should be strongly recommended rather than mandatory.

If you have any idea, feel free to suggest me. Also, I welcome just an
agreement expression about this idea.

- hyunsik

Re: [DISCUSS] patch review process

[ktpark <si...@gmail.com>]

+1 

I’m not familiar with review board but it really sounds good to me !!


2014. 1. 2., 오후 4:12, Hyunsik Choi <hy...@apache.org> 작성:

> Hi folks,
> 
> As the community and the number of contributors grow, more patches are
> being submitted. We have faced the increasing burden of patch peer
> review. So far,  we have mostly submitted patches to Jira and leaved
> comments on the corresponding JIRA issue. This way is not bad, but its
> productivity for review is not good.
> 
> In order to mitigate the burden of patch review, I propose that we
> should use reviewboard for more significant than minor issues.
> Reviewboard allows reviewers to directly add ideas and comments on the
> diff or source code. In addition, Reviewboard enables reviews to view
> the only difference between two patches. I think that they are really
> nice features. I believe we will experience more efficient and
> convenient review process if we use reviewboard more. I also think
> that this rule should be strongly recommended rather than mandatory.
> 
> If you have any idea, feel free to suggest me. Also, I welcome just an
> agreement expression about this idea.
> 
> - hyunsik

Re: [DISCUSS] patch review process

[Henry Saputra <he...@gmail.com>]

Hi Jihoon, I think we could make a script to help committer to copy
the comment commits when merging the commits from a pull requests so
when we commit to ASF git repo we preserve the commit comments from
their github private repo commits.

Or as Hyunsik mentioned, we could go with review board for classic
review and commit using ASF git repo directly.

- Henry

On Wed, Jan 1, 2014 at 11:57 PM, Jihoon Son <gh...@gmail.com> wrote:
> ++1.
> I love this suggestion.
>
> Henry, the pull request mechanism is also useful, but developers should
> maintain the commit logs in their branches.
> I think that it will be another burden for developers.
>
> Thanks.
>
> 2014/1/2 Henry Saputra <he...@gmail.com>
>
>> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
>> request mechanism to do the review and do manual merge by committers.
>>
>> Other podlings such as Apache Spark has been doing it and so far it
>> helps with reviews.
>>
>> - Henry
>>
>> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
>> > Hi folks,
>> >
>> > As the community and the number of contributors grow, more patches are
>> > being submitted. We have faced the increasing burden of patch peer
>> > review. So far,  we have mostly submitted patches to Jira and leaved
>> > comments on the corresponding JIRA issue. This way is not bad, but its
>> > productivity for review is not good.
>> >
>> > In order to mitigate the burden of patch review, I propose that we
>> > should use reviewboard for more significant than minor issues.
>> > Reviewboard allows reviewers to directly add ideas and comments on the
>> > diff or source code. In addition, Reviewboard enables reviews to view
>> > the only difference between two patches. I think that they are really
>> > nice features. I believe we will experience more efficient and
>> > convenient review process if we use reviewboard more. I also think
>> > that this rule should be strongly recommended rather than mandatory.
>> >
>> > If you have any idea, feel free to suggest me. Also, I welcome just an
>> > agreement expression about this idea.
>> >
>> > - hyunsik
>>
>
>
>
> --
> Jihoon Son
>
> Database & Information Systems Group,
> Prof. Yon Dohn Chung Lab.
> Dept. of Computer Science & Engineering,
> Korea University
> 1, 5-ga, Anam-dong, Seongbuk-gu,
> Seoul, 136-713, Republic of Korea
>
> Tel : +82-2-3290-3580
> E-mail : jihoonson@korea.ac.kr

Re: [DISCUSS] patch review process

[Jihoon Son <gh...@gmail.com>]

++1.
I love this suggestion.

Henry, the pull request mechanism is also useful, but developers should
maintain the commit logs in their branches.
I think that it will be another burden for developers.

Thanks.

2014/1/2 Henry Saputra <he...@gmail.com>

> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
> request mechanism to do the review and do manual merge by committers.
>
> Other podlings such as Apache Spark has been doing it and so far it
> helps with reviews.
>
> - Henry
>
> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
> > Hi folks,
> >
> > As the community and the number of contributors grow, more patches are
> > being submitted. We have faced the increasing burden of patch peer
> > review. So far,  we have mostly submitted patches to Jira and leaved
> > comments on the corresponding JIRA issue. This way is not bad, but its
> > productivity for review is not good.
> >
> > In order to mitigate the burden of patch review, I propose that we
> > should use reviewboard for more significant than minor issues.
> > Reviewboard allows reviewers to directly add ideas and comments on the
> > diff or source code. In addition, Reviewboard enables reviews to view
> > the only difference between two patches. I think that they are really
> > nice features. I believe we will experience more efficient and
> > convenient review process if we use reviewboard more. I also think
> > that this rule should be strongly recommended rather than mandatory.
> >
> > If you have any idea, feel free to suggest me. Also, I welcome just an
> > agreement expression about this idea.
> >
> > - hyunsik
>



-- 
Jihoon Son

Database & Information Systems Group,
Prof. Yon Dohn Chung Lab.
Dept. of Computer Science & Engineering,
Korea University
1, 5-ga, Anam-dong, Seongbuk-gu,
Seoul, 136-713, Republic of Korea

Tel : +82-2-3290-3580
E-mail : jihoonson@korea.ac.kr

Re: [DISCUSS] patch review process

[Hyunsik Choi <hy...@apache.org>]

FYI,

Few weeks ago, I asked ASF infra team to give the admin grants of
reviewboard to PMC members.
https://issues.apache.org/jira/browse/INFRA-7144.

The ask was resolved today. So, PMC members can close stale review
requests if you didn't creat those issues.

- hyunsik

On Sun, Jan 5, 2014 at 2:12 AM, Hyunsik Choi <hy...@apache.org> wrote:
> Thank you for your suggestions and comments.
>
> From now, review requests to reviewboard will be strongly recommended.
> However, very trivial patches would not submitted to Jira as I
> mentioned at the first time.
>
> According to this decision, I'll change HowToContribute page in the
> wiki and some pages in homepage. Also, I'll create some jira issues
> for additional tools that help us to use reviewboard.
>
> Thanks!
>
> On Thu, Jan 2, 2014 at 7:06 PM, Henry Saputra <he...@gmail.com> wrote:
>> Yeah but I think we could somehow sync Github and JIRA but I guess not
>> all devs comfortable with Github pull requests flow =)
>>
>> But for quick turnaround I think we could start easy with just using
>> reviewboard as review tool and JIRA as bug tracking tool.
>> Once a patch too bug for manual glance in the patch then contributor
>> should open RB ticket and add link in the JIRA, via manual or the
>> tools you mentioned.
>> If RB link is there then all comm about the patch should happen in the RB.
>>
>> I know Apache Shindig did it this way and been working well too.
>>
>> - Henry
>>
>> On Thu, Jan 2, 2014 at 12:59 AM, Hyunsik Choi <hy...@apache.org> wrote:
>>> Github looks cool. However, our situation is different from that of
>>> Spark. We have heavily used Jira for 10 months, while Spark community
>>> started with Github instead of Jira. If we use github and jira
>>> together, it is hard to track both system at the same time. It may be
>>> burden for many guys.
>>>
>>> I have been investigated more convenient way. It's combination looks cool.
>>>
>>> - Kafka Patch Review Tool
>>> (https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool)
>>>   - It enables users to submit a patch to the reviewboard and jira by
>>> just one line command
>>> - 'rbt patch' command
>>> (http://www.reviewboard.org/docs/rbtools/dev/rbt/commands/patch/)
>>>   - Once executed, It downloads and applies the latest or specified
>>> patch to a local source tree.
>>>
>>> With these utilities, we can make the following process.
>>>
>>> = Patch submission process =
>>> 1. A developer creates a jira issue.
>>> 2. A developer finishes the issue.
>>> 3. A developer uploads a patch to reviewboard and jira by using
>>> kafka's patch review tool.
>>> 4. A a developer transits the jira state to 'Patch Available'
>>> 5. Precommit-Tajo-Build job of Jenkins automatically builds the latest
>>> patch and does unit tests, and then jenkins will add the test result
>>> to the corresponding jira issue.
>>>
>>> = Review process =
>>> 1. A reviewer reviews and discusses the patch on the reviewboard
>>> 1.1 If necessary, a reviewer can download and apply the patch to the
>>> local source tree by executing one line 'rbt patch' command,
>>>
>>> - hyunsik
>>>
>>> On Thu, Jan 2, 2014 at 4:40 PM, Henry Saputra <he...@gmail.com> wrote:
>>>> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
>>>> request mechanism to do the review and do manual merge by committers.
>>>>
>>>> Other podlings such as Apache Spark has been doing it and so far it
>>>> helps with reviews.
>>>>
>>>> - Henry
>>>>
>>>> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
>>>>> Hi folks,
>>>>>
>>>>> As the community and the number of contributors grow, more patches are
>>>>> being submitted. We have faced the increasing burden of patch peer
>>>>> review. So far,  we have mostly submitted patches to Jira and leaved
>>>>> comments on the corresponding JIRA issue. This way is not bad, but its
>>>>> productivity for review is not good.
>>>>>
>>>>> In order to mitigate the burden of patch review, I propose that we
>>>>> should use reviewboard for more significant than minor issues.
>>>>> Reviewboard allows reviewers to directly add ideas and comments on the
>>>>> diff or source code. In addition, Reviewboard enables reviews to view
>>>>> the only difference between two patches. I think that they are really
>>>>> nice features. I believe we will experience more efficient and
>>>>> convenient review process if we use reviewboard more. I also think
>>>>> that this rule should be strongly recommended rather than mandatory.
>>>>>
>>>>> If you have any idea, feel free to suggest me. Also, I welcome just an
>>>>> agreement expression about this idea.
>>>>>
>>>>> - hyunsik

Re: [DISCUSS] patch review process

[Hyunsik Choi <hy...@apache.org>]

Thank you for your suggestions and comments.

>From now, review requests to reviewboard will be strongly recommended.
However, very trivial patches would not submitted to Jira as I
mentioned at the first time.

According to this decision, I'll change HowToContribute page in the
wiki and some pages in homepage. Also, I'll create some jira issues
for additional tools that help us to use reviewboard.

Thanks!

On Thu, Jan 2, 2014 at 7:06 PM, Henry Saputra <he...@gmail.com> wrote:
> Yeah but I think we could somehow sync Github and JIRA but I guess not
> all devs comfortable with Github pull requests flow =)
>
> But for quick turnaround I think we could start easy with just using
> reviewboard as review tool and JIRA as bug tracking tool.
> Once a patch too bug for manual glance in the patch then contributor
> should open RB ticket and add link in the JIRA, via manual or the
> tools you mentioned.
> If RB link is there then all comm about the patch should happen in the RB.
>
> I know Apache Shindig did it this way and been working well too.
>
> - Henry
>
> On Thu, Jan 2, 2014 at 12:59 AM, Hyunsik Choi <hy...@apache.org> wrote:
>> Github looks cool. However, our situation is different from that of
>> Spark. We have heavily used Jira for 10 months, while Spark community
>> started with Github instead of Jira. If we use github and jira
>> together, it is hard to track both system at the same time. It may be
>> burden for many guys.
>>
>> I have been investigated more convenient way. It's combination looks cool.
>>
>> - Kafka Patch Review Tool
>> (https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool)
>>   - It enables users to submit a patch to the reviewboard and jira by
>> just one line command
>> - 'rbt patch' command
>> (http://www.reviewboard.org/docs/rbtools/dev/rbt/commands/patch/)
>>   - Once executed, It downloads and applies the latest or specified
>> patch to a local source tree.
>>
>> With these utilities, we can make the following process.
>>
>> = Patch submission process =
>> 1. A developer creates a jira issue.
>> 2. A developer finishes the issue.
>> 3. A developer uploads a patch to reviewboard and jira by using
>> kafka's patch review tool.
>> 4. A a developer transits the jira state to 'Patch Available'
>> 5. Precommit-Tajo-Build job of Jenkins automatically builds the latest
>> patch and does unit tests, and then jenkins will add the test result
>> to the corresponding jira issue.
>>
>> = Review process =
>> 1. A reviewer reviews and discusses the patch on the reviewboard
>> 1.1 If necessary, a reviewer can download and apply the patch to the
>> local source tree by executing one line 'rbt patch' command,
>>
>> - hyunsik
>>
>> On Thu, Jan 2, 2014 at 4:40 PM, Henry Saputra <he...@gmail.com> wrote:
>>> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
>>> request mechanism to do the review and do manual merge by committers.
>>>
>>> Other podlings such as Apache Spark has been doing it and so far it
>>> helps with reviews.
>>>
>>> - Henry
>>>
>>> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
>>>> Hi folks,
>>>>
>>>> As the community and the number of contributors grow, more patches are
>>>> being submitted. We have faced the increasing burden of patch peer
>>>> review. So far,  we have mostly submitted patches to Jira and leaved
>>>> comments on the corresponding JIRA issue. This way is not bad, but its
>>>> productivity for review is not good.
>>>>
>>>> In order to mitigate the burden of patch review, I propose that we
>>>> should use reviewboard for more significant than minor issues.
>>>> Reviewboard allows reviewers to directly add ideas and comments on the
>>>> diff or source code. In addition, Reviewboard enables reviews to view
>>>> the only difference between two patches. I think that they are really
>>>> nice features. I believe we will experience more efficient and
>>>> convenient review process if we use reviewboard more. I also think
>>>> that this rule should be strongly recommended rather than mandatory.
>>>>
>>>> If you have any idea, feel free to suggest me. Also, I welcome just an
>>>> agreement expression about this idea.
>>>>
>>>> - hyunsik

Re: [DISCUSS] patch review process

[Henry Saputra <he...@gmail.com>]

Yeah but I think we could somehow sync Github and JIRA but I guess not
all devs comfortable with Github pull requests flow =)

But for quick turnaround I think we could start easy with just using
reviewboard as review tool and JIRA as bug tracking tool.
Once a patch too bug for manual glance in the patch then contributor
should open RB ticket and add link in the JIRA, via manual or the
tools you mentioned.
If RB link is there then all comm about the patch should happen in the RB.

I know Apache Shindig did it this way and been working well too.

- Henry

On Thu, Jan 2, 2014 at 12:59 AM, Hyunsik Choi <hy...@apache.org> wrote:
> Github looks cool. However, our situation is different from that of
> Spark. We have heavily used Jira for 10 months, while Spark community
> started with Github instead of Jira. If we use github and jira
> together, it is hard to track both system at the same time. It may be
> burden for many guys.
>
> I have been investigated more convenient way. It's combination looks cool.
>
> - Kafka Patch Review Tool
> (https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool)
>   - It enables users to submit a patch to the reviewboard and jira by
> just one line command
> - 'rbt patch' command
> (http://www.reviewboard.org/docs/rbtools/dev/rbt/commands/patch/)
>   - Once executed, It downloads and applies the latest or specified
> patch to a local source tree.
>
> With these utilities, we can make the following process.
>
> = Patch submission process =
> 1. A developer creates a jira issue.
> 2. A developer finishes the issue.
> 3. A developer uploads a patch to reviewboard and jira by using
> kafka's patch review tool.
> 4. A a developer transits the jira state to 'Patch Available'
> 5. Precommit-Tajo-Build job of Jenkins automatically builds the latest
> patch and does unit tests, and then jenkins will add the test result
> to the corresponding jira issue.
>
> = Review process =
> 1. A reviewer reviews and discusses the patch on the reviewboard
> 1.1 If necessary, a reviewer can download and apply the patch to the
> local source tree by executing one line 'rbt patch' command,
>
> - hyunsik
>
> On Thu, Jan 2, 2014 at 4:40 PM, Henry Saputra <he...@gmail.com> wrote:
>> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
>> request mechanism to do the review and do manual merge by committers.
>>
>> Other podlings such as Apache Spark has been doing it and so far it
>> helps with reviews.
>>
>> - Henry
>>
>> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
>>> Hi folks,
>>>
>>> As the community and the number of contributors grow, more patches are
>>> being submitted. We have faced the increasing burden of patch peer
>>> review. So far,  we have mostly submitted patches to Jira and leaved
>>> comments on the corresponding JIRA issue. This way is not bad, but its
>>> productivity for review is not good.
>>>
>>> In order to mitigate the burden of patch review, I propose that we
>>> should use reviewboard for more significant than minor issues.
>>> Reviewboard allows reviewers to directly add ideas and comments on the
>>> diff or source code. In addition, Reviewboard enables reviews to view
>>> the only difference between two patches. I think that they are really
>>> nice features. I believe we will experience more efficient and
>>> convenient review process if we use reviewboard more. I also think
>>> that this rule should be strongly recommended rather than mandatory.
>>>
>>> If you have any idea, feel free to suggest me. Also, I welcome just an
>>> agreement expression about this idea.
>>>
>>> - hyunsik

Re: [DISCUSS] patch review process

[Hyunsik Choi <hy...@apache.org>]

Github looks cool. However, our situation is different from that of
Spark. We have heavily used Jira for 10 months, while Spark community
started with Github instead of Jira. If we use github and jira
together, it is hard to track both system at the same time. It may be
burden for many guys.

I have been investigated more convenient way. It's combination looks cool.

- Kafka Patch Review Tool
(https://cwiki.apache.org/confluence/display/KAFKA/Kafka+patch+review+tool)
  - It enables users to submit a patch to the reviewboard and jira by
just one line command
- 'rbt patch' command
(http://www.reviewboard.org/docs/rbtools/dev/rbt/commands/patch/)
  - Once executed, It downloads and applies the latest or specified
patch to a local source tree.

With these utilities, we can make the following process.

= Patch submission process =
1. A developer creates a jira issue.
2. A developer finishes the issue.
3. A developer uploads a patch to reviewboard and jira by using
kafka's patch review tool.
4. A a developer transits the jira state to 'Patch Available'
5. Precommit-Tajo-Build job of Jenkins automatically builds the latest
patch and does unit tests, and then jenkins will add the test result
to the corresponding jira issue.

= Review process =
1. A reviewer reviews and discusses the patch on the reviewboard
1.1 If necessary, a reviewer can download and apply the patch to the
local source tree by executing one line 'rbt patch' command,

- hyunsik

On Thu, Jan 2, 2014 at 4:40 PM, Henry Saputra <he...@gmail.com> wrote:
> Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
> request mechanism to do the review and do manual merge by committers.
>
> Other podlings such as Apache Spark has been doing it and so far it
> helps with reviews.
>
> - Henry
>
> On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
>> Hi folks,
>>
>> As the community and the number of contributors grow, more patches are
>> being submitted. We have faced the increasing burden of patch peer
>> review. So far,  we have mostly submitted patches to Jira and leaved
>> comments on the corresponding JIRA issue. This way is not bad, but its
>> productivity for review is not good.
>>
>> In order to mitigate the burden of patch review, I propose that we
>> should use reviewboard for more significant than minor issues.
>> Reviewboard allows reviewers to directly add ideas and comments on the
>> diff or source code. In addition, Reviewboard enables reviews to view
>> the only difference between two patches. I think that they are really
>> nice features. I believe we will experience more efficient and
>> convenient review process if we use reviewboard more. I also think
>> that this rule should be strongly recommended rather than mandatory.
>>
>> If you have any idea, feel free to suggest me. Also, I welcome just an
>> agreement expression about this idea.
>>
>> - hyunsik

Re: [DISCUSS] patch review process

[Henry Saputra <he...@gmail.com>]

Hi Hyunsik, another alternative is to use ASF Github mirror repo pull
request mechanism to do the review and do manual merge by committers.

Other podlings such as Apache Spark has been doing it and so far it
helps with reviews.

- Henry

On Wed, Jan 1, 2014 at 11:12 PM, Hyunsik Choi <hy...@apache.org> wrote:
> Hi folks,
>
> As the community and the number of contributors grow, more patches are
> being submitted. We have faced the increasing burden of patch peer
> review. So far,  we have mostly submitted patches to Jira and leaved
> comments on the corresponding JIRA issue. This way is not bad, but its
> productivity for review is not good.
>
> In order to mitigate the burden of patch review, I propose that we
> should use reviewboard for more significant than minor issues.
> Reviewboard allows reviewers to directly add ideas and comments on the
> diff or source code. In addition, Reviewboard enables reviews to view
> the only difference between two patches. I think that they are really
> nice features. I believe we will experience more efficient and
> convenient review process if we use reviewboard more. I also think
> that this rule should be strongly recommended rather than mandatory.
>
> If you have any idea, feel free to suggest me. Also, I welcome just an
> agreement expression about this idea.
>
> - hyunsik

Re: [DISCUSS] patch review process

[Hyunsik Choi <hy...@apache.org>]

The precommit test is also on-going work.

You can track the progress at TAJO-166
(https://issues.apache.org/jira/browse/TAJO-166) with the followings:
https://issues.apache.org/jira/browse/INFRA-7149
https://builds.apache.org/job/PreCommit-Tajo-Build

- hyunsik

On Thu, Jan 2, 2014 at 4:17 PM, CharSyam <ch...@gmail.com> wrote:
> I think it is very good idea.
>
> I hope those kinds of jobs run automatically.
>
> 1] run "mvn clean install"
> after it successes.
> 2] adding diff to reviewboard.
>
>
>
> 2014/1/2 Hyunsik Choi <hy...@apache.org>
>
>> Hi folks,
>>
>> As the community and the number of contributors grow, more patches are
>> being submitted. We have faced the increasing burden of patch peer
>> review. So far,  we have mostly submitted patches to Jira and leaved
>> comments on the corresponding JIRA issue. This way is not bad, but its
>> productivity for review is not good.
>>
>> In order to mitigate the burden of patch review, I propose that we
>> should use reviewboard for more significant than minor issues.
>> Reviewboard allows reviewers to directly add ideas and comments on the
>> diff or source code. In addition, Reviewboard enables reviews to view
>> the only difference between two patches. I think that they are really
>> nice features. I believe we will experience more efficient and
>> convenient review process if we use reviewboard more. I also think
>> that this rule should be strongly recommended rather than mandatory.
>>
>> If you have any idea, feel free to suggest me. Also, I welcome just an
>> agreement expression about this idea.
>>
>> - hyunsik
>>

Re: [DISCUSS] patch review process

[CharSyam <ch...@gmail.com>]

I think it is very good idea.

I hope those kinds of jobs run automatically.

1] run "mvn clean install"
after it successes.
2] adding diff to reviewboard.



2014/1/2 Hyunsik Choi <hy...@apache.org>

> Hi folks,
>
> As the community and the number of contributors grow, more patches are
> being submitted. We have faced the increasing burden of patch peer
> review. So far,  we have mostly submitted patches to Jira and leaved
> comments on the corresponding JIRA issue. This way is not bad, but its
> productivity for review is not good.
>
> In order to mitigate the burden of patch review, I propose that we
> should use reviewboard for more significant than minor issues.
> Reviewboard allows reviewers to directly add ideas and comments on the
> diff or source code. In addition, Reviewboard enables reviews to view
> the only difference between two patches. I think that they are really
> nice features. I believe we will experience more efficient and
> convenient review process if we use reviewboard more. I also think
> that this rule should be strongly recommended rather than mandatory.
>
> If you have any idea, feel free to suggest me. Also, I welcome just an
> agreement expression about this idea.
>
> - hyunsik
>