tajo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henry Saputra <henry.sapu...@gmail.com>
Subject Re: [DISCUSS] patch review process
Date Thu, 02 Jan 2014 10:06:29 GMT
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

View raw message