tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyunsik Choi <hyun...@apache.org>
Subject Re: [DISCUSS] patch review process
Date Tue, 14 Jan 2014 13:44:04 GMT
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 <hyunsik@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 <henry.saputra@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 <hyunsik@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 <henry.saputra@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 <hyunsik@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

Mime
View raw message