You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by Alejandro Fernandez <af...@hortonworks.com> on 2016/06/02 16:55:57 UTC
Code Review groups
Hi committers and contributors,
I'm sure most of you have ran into this before; whenever I submit a code review I'm always curious to find out which reviewers I should include that are knowledgeable in that area.
So I'll typically run git blame to find the last 2-3 people that worked on those files, which takes time and may include reviewers no longer interested in that code area or miss reviewers that are interested.
I want to propose a wiki where developers sign up to be reviewers for a particular section, could be a feature, directory, etc.
Thoughts?
This allows developers to opt-in to areas of interest (even outside of their current expertise), should produce better code reviews, and make it easier for new contributors to find the right people.
Thank you,
Alejandro Fernandez
Re: Code Review groups
Posted by Yusaku Sako <yu...@hortonworks.com>.
+1.
Alejandro, do you want to create a starter wiki and let folks sign up for their areas of expertise?
Yusaku
On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com> wrote:
>+1. Makes sense.
>
>Thanks.
>
>Regards,
>Swapan.
>
>
>
>
>
>
>
>
>
>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>
>>Alejandro, I agree. I just hope we (as a group) can manage the wiki page without letting it get too stale over time.
>>
>>+1
>>
>>Rob
>>
>>
>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com> wrote:
>>
>>>Hi committers and contributors,
>>>
>>>I'm sure most of you have ran into this before; whenever I submit a code review I'm always curious to find out which reviewers I should include that are knowledgeable in that area.
>>>So I'll typically run git blame to find the last 2-3 people that worked on those files, which takes time and may include reviewers no longer interested in that code area or miss reviewers that are interested.
>>>I want to propose a wiki where developers sign up to be reviewers for a particular section, could be a feature, directory, etc.
>>>
>>>Thoughts?
>>>
>>>This allows developers to opt-in to areas of interest (even outside of their current expertise), should produce better code reviews, and make it easier for new contributors to find the right people.
>>>
>>>Thank you,
>>>Alejandro Fernandez
>>>
>>
Re: Code Review groups
Posted by Masahiro Tanaka <pl...@gmail.com>.
Hi Yusaku,
I think testing GitHub pull request model is a good idea. We should
confirm the value of pull-request model before we switch.
I would like to help writing a draft for the contribution guide.
Re: Code Review groups
Posted by Yusaku Sako <yu...@hortonworks.com>.
Hi Masahiro,
I think it's definitely worth looking into using the Github PR model.
Apache Spark's contribution guide is very detailed so it could be a good starter reference for us: https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark
Since publishing patches and doing code reviews on Github PR vs the traditional way are not mutually exclusive, we can experiment and see how we (the contributors/committers) likes it. If the response is positive, we can do a total switch over to the Github PR model.
BTW other Apache projects, such as Apache Flink, use the Github PR model as well: https://flink.apache.org/contribute-code.html
Does anyone want to volunteer to write a draft for the contribution guide?
Yusaku
On 7/14/16, 2:01 PM, "田中正浩" <pl...@gmail.com> wrote:
>Hi committers and contributors,
>
>First of all, thanks Alejandro for your suggestion!
>
>I'm curious about the review process of Apache Ambari.
>Some of you said using ReviewBoard tended to be redundant,
>and I agree with that argument as just a newbie contributor.
>
>I think GitHub pull-request model would be preferable, as Mithun said.
>Apache Spark project seems to be doing well in this model and
>it is useful as a reference.
>
>Thank you,
>Masahiro Tanaka
>
>2016-06-04 2:06 GMT+09:00 Aravindan Vijayan <av...@hortonworks.com>:
>> +1
>>
>> Nice suggestion Alejandro!
>>
>> --
>> Thanks and Regards,
>> Aravindan Vijayan
>>
>>
>>
>>
>>
>>
>>
>>
>> On 6/2/16, 11:31 PM, "Gautam Borad" <gb...@gmail.com> wrote:
>>
>>>+1 for Alejandro's suggestion for review groups.
>>>
>>>My +1 for github-based pull request process. Its way easy/simpler than
>>>Review board and works well with a git-based workflow.
>>>Also, we can expect new features every
>>><https://github.com/blog/2111-issue-and-pull-request-templates> now
>>><https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments>
>>>and then <https://github.com/blog/2123-more-code-review-tools>!
>>>
>>>On Fri, Jun 3, 2016 at 7:46 AM, Jungtaek Lim <ka...@gmail.com> wrote:
>>>
>>>> As I'm just newbie contributors, I'm happy to respect the Ambari project
>>>> policy, but if we would want to consider to revisit review process, I'd +1
>>>> on Mithun.
>>>> I just submitted two patches (may submit some more), and triggering Jenkins
>>>> and submitting patch to review system was hurdle so that I was struggling
>>>> several hours for that.
>>>> And we can see the pull requests on Github mirror though project doesn't
>>>> take pull request. It's well-known and easy way for open source
>>>> contributors to participate.
>>>>
>>>> Thanks,
>>>> Jungtaek Lim (HeartSaVioR)
>>>>
>>>> 2016년 6월 3일 (금) 오전 10:58, Mithun Mathew <mi...@gmail.com>님이 작성:
>>>>
>>>> > Just putting some thoughts in regarding the review board model:
>>>> > Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
>>>> > listed in the JIRA (summary, description, branch, JIRA no, group, and
>>>> > upload the same patch) to the review board - to me it is quite a lot of
>>>> > redundant work.
>>>> >
>>>> > The Github pull request model with CI kicking off as soon as pull request
>>>> > is made is ideal and I consider this to be more efficient.
>>>> >
>>>> > Anyone else have similar thoughts?
>>>> >
>>>> > On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
>>>> > afernandez@hortonworks.com> wrote:
>>>> >
>>>> > > Thank you for the feedback. I created
>>>> > >
>>>> >
>>>> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
>>>> > > as a starting point.
>>>> > > I'm also looking into our workflow to see the pros/cons of switching to
>>>> > > github + pull request model, or another code review provider with more
>>>> > > advanced features.
>>>> > >
>>>> > > Thanks,
>>>> > > Alejandro
>>>> > >
>>>> > >
>>>> > > On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>>>> > >
>>>> > > >We can look into the already available component names in the JIRA for
>>>> > > >the initial list.
>>>> > > >We should not create fine-grained groups and aim to have at least 3-5
>>>> > > >devs (more is better) in a single component/area.
>>>> > > >
>>>> > > >Possible list:
>>>> > > >ambari-web
>>>> > > >ambari-views
>>>> > > >ambari-server
>>>> > > >ambari-agent
>>>> > > >stacks-framework/extensibility
>>>> > > >stack-definitions (this could break into separate services)
>>>> > > >blueprints
>>>> > > >alerts/metrics
>>>> > > >logsearch
>>>> > > >security/kerberos/ldap
>>>> > > >stack-upgrade/RU/EU
>>>> > > >
>>>> > > >Once the list is final lets make sure that the available list of
>>>> > > >components in the JIRA matches this list.
>>>> > > >
>>>> > > >This is probably also a good opportunity to see if there are better
>>>> > > >alternatives to reviews.apache.org.
>>>> > > >
>>>> > > >regards
>>>> > > >Sumit
>>>> > > >________________________________________
>>>> > > >From: Jayush Luniya <jl...@hortonworks.com>
>>>> > > >Sent: Thursday, June 02, 2016 1:47 PM
>>>> > > >To: dev@ambari.apache.org
>>>> > > >Subject: Re: Code Review groups
>>>> > > >
>>>> > > >+1 on this
>>>> > > >
>>>> > > >
>>>> > > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com>
>>>> > wrote:
>>>> > > >
>>>> > > >>+1. Makes sense.
>>>> > > >>
>>>> > > >>Thanks.
>>>> > > >>
>>>> > > >>Regards,
>>>> > > >>Swapan.
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>
>>>> > > >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>>>> > > >>
>>>> > > >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>>>> > > >>>page without letting it get too stale over time.
>>>> > > >>>
>>>> > > >>>+1
>>>> > > >>>
>>>> > > >>>Rob
>>>> > > >>>
>>>> > > >>>
>>>> > > >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <
>>>> > afernandez@hortonworks.com>
>>>> > > >>>wrote:
>>>> > > >>>
>>>> > > >>>>Hi committers and contributors,
>>>> > > >>>>
>>>> > > >>>>I'm sure most of you have ran into this before; whenever I submit a
>>>> > > >>>>code review I'm always curious to find out which reviewers I should
>>>> > > >>>>include that are knowledgeable in that area.
>>>> > > >>>>So I'll typically run git blame to find the last 2-3 people that
>>>> > worked
>>>> > > >>>>on those files, which takes time and may include reviewers no
>>>> longer
>>>> > > >>>>interested in that code area or miss reviewers that are interested.
>>>> > > >>>>I want to propose a wiki where developers sign up to be reviewers
>>>> > for a
>>>> > > >>>>particular section, could be a feature, directory, etc.
>>>> > > >>>>
>>>> > > >>>>Thoughts?
>>>> > > >>>>
>>>> > > >>>>This allows developers to opt-in to areas of interest (even outside
>>>> > of
>>>> > > >>>>their current expertise), should produce better code reviews, and
>>>> > make
>>>> > > >>>>it easier for new contributors to find the right people.
>>>> > > >>>>
>>>> > > >>>>Thank you,
>>>> > > >>>>Alejandro Fernandez
>>>> > > >>>>
>>>> > > >>>
>>>> > > >
>>>> > > >
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > *Mithun Mathew* (Matt)
>>>> >
>>>> > - www.linkedin.com/in/mithunmatt/
>>>> >
>>>>
>>>
>>>
>>>
>>>--
>>>Regards,
>>>Gautam.
>
Re: Code Review groups
Posted by 田中正浩 <pl...@gmail.com>.
Hi committers and contributors,
First of all, thanks Alejandro for your suggestion!
I'm curious about the review process of Apache Ambari.
Some of you said using ReviewBoard tended to be redundant,
and I agree with that argument as just a newbie contributor.
I think GitHub pull-request model would be preferable, as Mithun said.
Apache Spark project seems to be doing well in this model and
it is useful as a reference.
Thank you,
Masahiro Tanaka
2016-06-04 2:06 GMT+09:00 Aravindan Vijayan <av...@hortonworks.com>:
> +1
>
> Nice suggestion Alejandro!
>
> --
> Thanks and Regards,
> Aravindan Vijayan
>
>
>
>
>
>
>
>
> On 6/2/16, 11:31 PM, "Gautam Borad" <gb...@gmail.com> wrote:
>
>>+1 for Alejandro's suggestion for review groups.
>>
>>My +1 for github-based pull request process. Its way easy/simpler than
>>Review board and works well with a git-based workflow.
>>Also, we can expect new features every
>><https://github.com/blog/2111-issue-and-pull-request-templates> now
>><https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments>
>>and then <https://github.com/blog/2123-more-code-review-tools>!
>>
>>On Fri, Jun 3, 2016 at 7:46 AM, Jungtaek Lim <ka...@gmail.com> wrote:
>>
>>> As I'm just newbie contributors, I'm happy to respect the Ambari project
>>> policy, but if we would want to consider to revisit review process, I'd +1
>>> on Mithun.
>>> I just submitted two patches (may submit some more), and triggering Jenkins
>>> and submitting patch to review system was hurdle so that I was struggling
>>> several hours for that.
>>> And we can see the pull requests on Github mirror though project doesn't
>>> take pull request. It's well-known and easy way for open source
>>> contributors to participate.
>>>
>>> Thanks,
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2016년 6월 3일 (금) 오전 10:58, Mithun Mathew <mi...@gmail.com>님이 작성:
>>>
>>> > Just putting some thoughts in regarding the review board model:
>>> > Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
>>> > listed in the JIRA (summary, description, branch, JIRA no, group, and
>>> > upload the same patch) to the review board - to me it is quite a lot of
>>> > redundant work.
>>> >
>>> > The Github pull request model with CI kicking off as soon as pull request
>>> > is made is ideal and I consider this to be more efficient.
>>> >
>>> > Anyone else have similar thoughts?
>>> >
>>> > On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
>>> > afernandez@hortonworks.com> wrote:
>>> >
>>> > > Thank you for the feedback. I created
>>> > >
>>> >
>>> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
>>> > > as a starting point.
>>> > > I'm also looking into our workflow to see the pros/cons of switching to
>>> > > github + pull request model, or another code review provider with more
>>> > > advanced features.
>>> > >
>>> > > Thanks,
>>> > > Alejandro
>>> > >
>>> > >
>>> > > On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>>> > >
>>> > > >We can look into the already available component names in the JIRA for
>>> > > >the initial list.
>>> > > >We should not create fine-grained groups and aim to have at least 3-5
>>> > > >devs (more is better) in a single component/area.
>>> > > >
>>> > > >Possible list:
>>> > > >ambari-web
>>> > > >ambari-views
>>> > > >ambari-server
>>> > > >ambari-agent
>>> > > >stacks-framework/extensibility
>>> > > >stack-definitions (this could break into separate services)
>>> > > >blueprints
>>> > > >alerts/metrics
>>> > > >logsearch
>>> > > >security/kerberos/ldap
>>> > > >stack-upgrade/RU/EU
>>> > > >
>>> > > >Once the list is final lets make sure that the available list of
>>> > > >components in the JIRA matches this list.
>>> > > >
>>> > > >This is probably also a good opportunity to see if there are better
>>> > > >alternatives to reviews.apache.org.
>>> > > >
>>> > > >regards
>>> > > >Sumit
>>> > > >________________________________________
>>> > > >From: Jayush Luniya <jl...@hortonworks.com>
>>> > > >Sent: Thursday, June 02, 2016 1:47 PM
>>> > > >To: dev@ambari.apache.org
>>> > > >Subject: Re: Code Review groups
>>> > > >
>>> > > >+1 on this
>>> > > >
>>> > > >
>>> > > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com>
>>> > wrote:
>>> > > >
>>> > > >>+1. Makes sense.
>>> > > >>
>>> > > >>Thanks.
>>> > > >>
>>> > > >>Regards,
>>> > > >>Swapan.
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>
>>> > > >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>>> > > >>
>>> > > >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>>> > > >>>page without letting it get too stale over time.
>>> > > >>>
>>> > > >>>+1
>>> > > >>>
>>> > > >>>Rob
>>> > > >>>
>>> > > >>>
>>> > > >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <
>>> > afernandez@hortonworks.com>
>>> > > >>>wrote:
>>> > > >>>
>>> > > >>>>Hi committers and contributors,
>>> > > >>>>
>>> > > >>>>I'm sure most of you have ran into this before; whenever I submit a
>>> > > >>>>code review I'm always curious to find out which reviewers I should
>>> > > >>>>include that are knowledgeable in that area.
>>> > > >>>>So I'll typically run git blame to find the last 2-3 people that
>>> > worked
>>> > > >>>>on those files, which takes time and may include reviewers no
>>> longer
>>> > > >>>>interested in that code area or miss reviewers that are interested.
>>> > > >>>>I want to propose a wiki where developers sign up to be reviewers
>>> > for a
>>> > > >>>>particular section, could be a feature, directory, etc.
>>> > > >>>>
>>> > > >>>>Thoughts?
>>> > > >>>>
>>> > > >>>>This allows developers to opt-in to areas of interest (even outside
>>> > of
>>> > > >>>>their current expertise), should produce better code reviews, and
>>> > make
>>> > > >>>>it easier for new contributors to find the right people.
>>> > > >>>>
>>> > > >>>>Thank you,
>>> > > >>>>Alejandro Fernandez
>>> > > >>>>
>>> > > >>>
>>> > > >
>>> > > >
>>> > >
>>> > >
>>> >
>>> >
>>> > --
>>> > *Mithun Mathew* (Matt)
>>> >
>>> > - www.linkedin.com/in/mithunmatt/
>>> >
>>>
>>
>>
>>
>>--
>>Regards,
>>Gautam.
Re: Code Review groups
Posted by Aravindan Vijayan <av...@hortonworks.com>.
+1
Nice suggestion Alejandro!
--
Thanks and Regards,
Aravindan Vijayan
On 6/2/16, 11:31 PM, "Gautam Borad" <gb...@gmail.com> wrote:
>+1 for Alejandro's suggestion for review groups.
>
>My +1 for github-based pull request process. Its way easy/simpler than
>Review board and works well with a git-based workflow.
>Also, we can expect new features every
><https://github.com/blog/2111-issue-and-pull-request-templates> now
><https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments>
>and then <https://github.com/blog/2123-more-code-review-tools>!
>
>On Fri, Jun 3, 2016 at 7:46 AM, Jungtaek Lim <ka...@gmail.com> wrote:
>
>> As I'm just newbie contributors, I'm happy to respect the Ambari project
>> policy, but if we would want to consider to revisit review process, I'd +1
>> on Mithun.
>> I just submitted two patches (may submit some more), and triggering Jenkins
>> and submitting patch to review system was hurdle so that I was struggling
>> several hours for that.
>> And we can see the pull requests on Github mirror though project doesn't
>> take pull request. It's well-known and easy way for open source
>> contributors to participate.
>>
>> Thanks,
>> Jungtaek Lim (HeartSaVioR)
>>
>> 2016년 6월 3일 (금) 오전 10:58, Mithun Mathew <mi...@gmail.com>님이 작성:
>>
>> > Just putting some thoughts in regarding the review board model:
>> > Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
>> > listed in the JIRA (summary, description, branch, JIRA no, group, and
>> > upload the same patch) to the review board - to me it is quite a lot of
>> > redundant work.
>> >
>> > The Github pull request model with CI kicking off as soon as pull request
>> > is made is ideal and I consider this to be more efficient.
>> >
>> > Anyone else have similar thoughts?
>> >
>> > On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
>> > afernandez@hortonworks.com> wrote:
>> >
>> > > Thank you for the feedback. I created
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
>> > > as a starting point.
>> > > I'm also looking into our workflow to see the pros/cons of switching to
>> > > github + pull request model, or another code review provider with more
>> > > advanced features.
>> > >
>> > > Thanks,
>> > > Alejandro
>> > >
>> > >
>> > > On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>> > >
>> > > >We can look into the already available component names in the JIRA for
>> > > >the initial list.
>> > > >We should not create fine-grained groups and aim to have at least 3-5
>> > > >devs (more is better) in a single component/area.
>> > > >
>> > > >Possible list:
>> > > >ambari-web
>> > > >ambari-views
>> > > >ambari-server
>> > > >ambari-agent
>> > > >stacks-framework/extensibility
>> > > >stack-definitions (this could break into separate services)
>> > > >blueprints
>> > > >alerts/metrics
>> > > >logsearch
>> > > >security/kerberos/ldap
>> > > >stack-upgrade/RU/EU
>> > > >
>> > > >Once the list is final lets make sure that the available list of
>> > > >components in the JIRA matches this list.
>> > > >
>> > > >This is probably also a good opportunity to see if there are better
>> > > >alternatives to reviews.apache.org.
>> > > >
>> > > >regards
>> > > >Sumit
>> > > >________________________________________
>> > > >From: Jayush Luniya <jl...@hortonworks.com>
>> > > >Sent: Thursday, June 02, 2016 1:47 PM
>> > > >To: dev@ambari.apache.org
>> > > >Subject: Re: Code Review groups
>> > > >
>> > > >+1 on this
>> > > >
>> > > >
>> > > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com>
>> > wrote:
>> > > >
>> > > >>+1. Makes sense.
>> > > >>
>> > > >>Thanks.
>> > > >>
>> > > >>Regards,
>> > > >>Swapan.
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>> > > >>
>> > > >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>> > > >>>page without letting it get too stale over time.
>> > > >>>
>> > > >>>+1
>> > > >>>
>> > > >>>Rob
>> > > >>>
>> > > >>>
>> > > >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <
>> > afernandez@hortonworks.com>
>> > > >>>wrote:
>> > > >>>
>> > > >>>>Hi committers and contributors,
>> > > >>>>
>> > > >>>>I'm sure most of you have ran into this before; whenever I submit a
>> > > >>>>code review I'm always curious to find out which reviewers I should
>> > > >>>>include that are knowledgeable in that area.
>> > > >>>>So I'll typically run git blame to find the last 2-3 people that
>> > worked
>> > > >>>>on those files, which takes time and may include reviewers no
>> longer
>> > > >>>>interested in that code area or miss reviewers that are interested.
>> > > >>>>I want to propose a wiki where developers sign up to be reviewers
>> > for a
>> > > >>>>particular section, could be a feature, directory, etc.
>> > > >>>>
>> > > >>>>Thoughts?
>> > > >>>>
>> > > >>>>This allows developers to opt-in to areas of interest (even outside
>> > of
>> > > >>>>their current expertise), should produce better code reviews, and
>> > make
>> > > >>>>it easier for new contributors to find the right people.
>> > > >>>>
>> > > >>>>Thank you,
>> > > >>>>Alejandro Fernandez
>> > > >>>>
>> > > >>>
>> > > >
>> > > >
>> > >
>> > >
>> >
>> >
>> > --
>> > *Mithun Mathew* (Matt)
>> >
>> > - www.linkedin.com/in/mithunmatt/
>> >
>>
>
>
>
>--
>Regards,
>Gautam.
Re: Code Review groups
Posted by Gautam Borad <gb...@gmail.com>.
+1 for Alejandro's suggestion for review groups.
My +1 for github-based pull request process. Its way easy/simpler than
Review board and works well with a git-based workflow.
Also, we can expect new features every
<https://github.com/blog/2111-issue-and-pull-request-templates> now
<https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments>
and then <https://github.com/blog/2123-more-code-review-tools>!
On Fri, Jun 3, 2016 at 7:46 AM, Jungtaek Lim <ka...@gmail.com> wrote:
> As I'm just newbie contributors, I'm happy to respect the Ambari project
> policy, but if we would want to consider to revisit review process, I'd +1
> on Mithun.
> I just submitted two patches (may submit some more), and triggering Jenkins
> and submitting patch to review system was hurdle so that I was struggling
> several hours for that.
> And we can see the pull requests on Github mirror though project doesn't
> take pull request. It's well-known and easy way for open source
> contributors to participate.
>
> Thanks,
> Jungtaek Lim (HeartSaVioR)
>
> 2016년 6월 3일 (금) 오전 10:58, Mithun Mathew <mi...@gmail.com>님이 작성:
>
> > Just putting some thoughts in regarding the review board model:
> > Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
> > listed in the JIRA (summary, description, branch, JIRA no, group, and
> > upload the same patch) to the review board - to me it is quite a lot of
> > redundant work.
> >
> > The Github pull request model with CI kicking off as soon as pull request
> > is made is ideal and I consider this to be more efficient.
> >
> > Anyone else have similar thoughts?
> >
> > On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
> > afernandez@hortonworks.com> wrote:
> >
> > > Thank you for the feedback. I created
> > >
> >
> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
> > > as a starting point.
> > > I'm also looking into our workflow to see the pros/cons of switching to
> > > github + pull request model, or another code review provider with more
> > > advanced features.
> > >
> > > Thanks,
> > > Alejandro
> > >
> > >
> > > On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
> > >
> > > >We can look into the already available component names in the JIRA for
> > > >the initial list.
> > > >We should not create fine-grained groups and aim to have at least 3-5
> > > >devs (more is better) in a single component/area.
> > > >
> > > >Possible list:
> > > >ambari-web
> > > >ambari-views
> > > >ambari-server
> > > >ambari-agent
> > > >stacks-framework/extensibility
> > > >stack-definitions (this could break into separate services)
> > > >blueprints
> > > >alerts/metrics
> > > >logsearch
> > > >security/kerberos/ldap
> > > >stack-upgrade/RU/EU
> > > >
> > > >Once the list is final lets make sure that the available list of
> > > >components in the JIRA matches this list.
> > > >
> > > >This is probably also a good opportunity to see if there are better
> > > >alternatives to reviews.apache.org.
> > > >
> > > >regards
> > > >Sumit
> > > >________________________________________
> > > >From: Jayush Luniya <jl...@hortonworks.com>
> > > >Sent: Thursday, June 02, 2016 1:47 PM
> > > >To: dev@ambari.apache.org
> > > >Subject: Re: Code Review groups
> > > >
> > > >+1 on this
> > > >
> > > >
> > > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com>
> > wrote:
> > > >
> > > >>+1. Makes sense.
> > > >>
> > > >>Thanks.
> > > >>
> > > >>Regards,
> > > >>Swapan.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>
> > > >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
> > > >>
> > > >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
> > > >>>page without letting it get too stale over time.
> > > >>>
> > > >>>+1
> > > >>>
> > > >>>Rob
> > > >>>
> > > >>>
> > > >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <
> > afernandez@hortonworks.com>
> > > >>>wrote:
> > > >>>
> > > >>>>Hi committers and contributors,
> > > >>>>
> > > >>>>I'm sure most of you have ran into this before; whenever I submit a
> > > >>>>code review I'm always curious to find out which reviewers I should
> > > >>>>include that are knowledgeable in that area.
> > > >>>>So I'll typically run git blame to find the last 2-3 people that
> > worked
> > > >>>>on those files, which takes time and may include reviewers no
> longer
> > > >>>>interested in that code area or miss reviewers that are interested.
> > > >>>>I want to propose a wiki where developers sign up to be reviewers
> > for a
> > > >>>>particular section, could be a feature, directory, etc.
> > > >>>>
> > > >>>>Thoughts?
> > > >>>>
> > > >>>>This allows developers to opt-in to areas of interest (even outside
> > of
> > > >>>>their current expertise), should produce better code reviews, and
> > make
> > > >>>>it easier for new contributors to find the right people.
> > > >>>>
> > > >>>>Thank you,
> > > >>>>Alejandro Fernandez
> > > >>>>
> > > >>>
> > > >
> > > >
> > >
> > >
> >
> >
> > --
> > *Mithun Mathew* (Matt)
> >
> > - www.linkedin.com/in/mithunmatt/
> >
>
--
Regards,
Gautam.
Re: Code Review groups
Posted by Jungtaek Lim <ka...@gmail.com>.
As I'm just newbie contributors, I'm happy to respect the Ambari project
policy, but if we would want to consider to revisit review process, I'd +1
on Mithun.
I just submitted two patches (may submit some more), and triggering Jenkins
and submitting patch to review system was hurdle so that I was struggling
several hours for that.
And we can see the pull requests on Github mirror though project doesn't
take pull request. It's well-known and easy way for open source
contributors to participate.
Thanks,
Jungtaek Lim (HeartSaVioR)
2016년 6월 3일 (금) 오전 10:58, Mithun Mathew <mi...@gmail.com>님이 작성:
> Just putting some thoughts in regarding the review board model:
> Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
> listed in the JIRA (summary, description, branch, JIRA no, group, and
> upload the same patch) to the review board - to me it is quite a lot of
> redundant work.
>
> The Github pull request model with CI kicking off as soon as pull request
> is made is ideal and I consider this to be more efficient.
>
> Anyone else have similar thoughts?
>
> On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
> afernandez@hortonworks.com> wrote:
>
> > Thank you for the feedback. I created
> >
> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
> > as a starting point.
> > I'm also looking into our workflow to see the pros/cons of switching to
> > github + pull request model, or another code review provider with more
> > advanced features.
> >
> > Thanks,
> > Alejandro
> >
> >
> > On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
> >
> > >We can look into the already available component names in the JIRA for
> > >the initial list.
> > >We should not create fine-grained groups and aim to have at least 3-5
> > >devs (more is better) in a single component/area.
> > >
> > >Possible list:
> > >ambari-web
> > >ambari-views
> > >ambari-server
> > >ambari-agent
> > >stacks-framework/extensibility
> > >stack-definitions (this could break into separate services)
> > >blueprints
> > >alerts/metrics
> > >logsearch
> > >security/kerberos/ldap
> > >stack-upgrade/RU/EU
> > >
> > >Once the list is final lets make sure that the available list of
> > >components in the JIRA matches this list.
> > >
> > >This is probably also a good opportunity to see if there are better
> > >alternatives to reviews.apache.org.
> > >
> > >regards
> > >Sumit
> > >________________________________________
> > >From: Jayush Luniya <jl...@hortonworks.com>
> > >Sent: Thursday, June 02, 2016 1:47 PM
> > >To: dev@ambari.apache.org
> > >Subject: Re: Code Review groups
> > >
> > >+1 on this
> > >
> > >
> > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com>
> wrote:
> > >
> > >>+1. Makes sense.
> > >>
> > >>Thanks.
> > >>
> > >>Regards,
> > >>Swapan.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
> > >>
> > >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
> > >>>page without letting it get too stale over time.
> > >>>
> > >>>+1
> > >>>
> > >>>Rob
> > >>>
> > >>>
> > >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <
> afernandez@hortonworks.com>
> > >>>wrote:
> > >>>
> > >>>>Hi committers and contributors,
> > >>>>
> > >>>>I'm sure most of you have ran into this before; whenever I submit a
> > >>>>code review I'm always curious to find out which reviewers I should
> > >>>>include that are knowledgeable in that area.
> > >>>>So I'll typically run git blame to find the last 2-3 people that
> worked
> > >>>>on those files, which takes time and may include reviewers no longer
> > >>>>interested in that code area or miss reviewers that are interested.
> > >>>>I want to propose a wiki where developers sign up to be reviewers
> for a
> > >>>>particular section, could be a feature, directory, etc.
> > >>>>
> > >>>>Thoughts?
> > >>>>
> > >>>>This allows developers to opt-in to areas of interest (even outside
> of
> > >>>>their current expertise), should produce better code reviews, and
> make
> > >>>>it easier for new contributors to find the right people.
> > >>>>
> > >>>>Thank you,
> > >>>>Alejandro Fernandez
> > >>>>
> > >>>
> > >
> > >
> >
> >
>
>
> --
> *Mithun Mathew* (Matt)
>
> - www.linkedin.com/in/mithunmatt/
>
Re: Code Review groups
Posted by Mithun Mathew <mi...@gmail.com>.
Just putting some thoughts in regarding the review board model:
Every time (I mean EVERY TIME!), I have to copy a bunch of things that I
listed in the JIRA (summary, description, branch, JIRA no, group, and
upload the same patch) to the review board - to me it is quite a lot of
redundant work.
The Github pull request model with CI kicking off as soon as pull request
is made is ideal and I consider this to be more efficient.
Anyone else have similar thoughts?
On Thu, Jun 2, 2016 at 2:17 PM, Alejandro Fernandez <
afernandez@hortonworks.com> wrote:
> Thank you for the feedback. I created
> https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
> as a starting point.
> I'm also looking into our workflow to see the pros/cons of switching to
> github + pull request model, or another code review provider with more
> advanced features.
>
> Thanks,
> Alejandro
>
>
> On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>
> >We can look into the already available component names in the JIRA for
> >the initial list.
> >We should not create fine-grained groups and aim to have at least 3-5
> >devs (more is better) in a single component/area.
> >
> >Possible list:
> >ambari-web
> >ambari-views
> >ambari-server
> >ambari-agent
> >stacks-framework/extensibility
> >stack-definitions (this could break into separate services)
> >blueprints
> >alerts/metrics
> >logsearch
> >security/kerberos/ldap
> >stack-upgrade/RU/EU
> >
> >Once the list is final lets make sure that the available list of
> >components in the JIRA matches this list.
> >
> >This is probably also a good opportunity to see if there are better
> >alternatives to reviews.apache.org.
> >
> >regards
> >Sumit
> >________________________________________
> >From: Jayush Luniya <jl...@hortonworks.com>
> >Sent: Thursday, June 02, 2016 1:47 PM
> >To: dev@ambari.apache.org
> >Subject: Re: Code Review groups
> >
> >+1 on this
> >
> >
> >On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com> wrote:
> >
> >>+1. Makes sense.
> >>
> >>Thanks.
> >>
> >>Regards,
> >>Swapan.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
> >>
> >>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
> >>>page without letting it get too stale over time.
> >>>
> >>>+1
> >>>
> >>>Rob
> >>>
> >>>
> >>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com>
> >>>wrote:
> >>>
> >>>>Hi committers and contributors,
> >>>>
> >>>>I'm sure most of you have ran into this before; whenever I submit a
> >>>>code review I'm always curious to find out which reviewers I should
> >>>>include that are knowledgeable in that area.
> >>>>So I'll typically run git blame to find the last 2-3 people that worked
> >>>>on those files, which takes time and may include reviewers no longer
> >>>>interested in that code area or miss reviewers that are interested.
> >>>>I want to propose a wiki where developers sign up to be reviewers for a
> >>>>particular section, could be a feature, directory, etc.
> >>>>
> >>>>Thoughts?
> >>>>
> >>>>This allows developers to opt-in to areas of interest (even outside of
> >>>>their current expertise), should produce better code reviews, and make
> >>>>it easier for new contributors to find the right people.
> >>>>
> >>>>Thank you,
> >>>>Alejandro Fernandez
> >>>>
> >>>
> >
> >
>
>
--
*Mithun Mathew* (Matt)
- www.linkedin.com/in/mithunmatt/
Re: Code Review groups
Posted by Alejandro Fernandez <af...@hortonworks.com>.
Thank you for the feedback. I created
https://cwiki.apache.org/confluence/display/AMBARI/Code+Review+Guidelines
as a starting point.
I'm also looking into our workflow to see the pros/cons of switching to
github + pull request model, or another code review provider with more
advanced features.
Thanks,
Alejandro
On 6/2/16, 2:02 PM, "Sumit Mohanty" <sm...@hortonworks.com> wrote:
>We can look into the already available component names in the JIRA for
>the initial list.
>We should not create fine-grained groups and aim to have at least 3-5
>devs (more is better) in a single component/area.
>
>Possible list:
>ambari-web
>ambari-views
>ambari-server
>ambari-agent
>stacks-framework/extensibility
>stack-definitions (this could break into separate services)
>blueprints
>alerts/metrics
>logsearch
>security/kerberos/ldap
>stack-upgrade/RU/EU
>
>Once the list is final lets make sure that the available list of
>components in the JIRA matches this list.
>
>This is probably also a good opportunity to see if there are better
>alternatives to reviews.apache.org.
>
>regards
>Sumit
>________________________________________
>From: Jayush Luniya <jl...@hortonworks.com>
>Sent: Thursday, June 02, 2016 1:47 PM
>To: dev@ambari.apache.org
>Subject: Re: Code Review groups
>
>+1 on this
>
>
>On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com> wrote:
>
>>+1. Makes sense.
>>
>>Thanks.
>>
>>Regards,
>>Swapan.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>>
>>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>>>page without letting it get too stale over time.
>>>
>>>+1
>>>
>>>Rob
>>>
>>>
>>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com>
>>>wrote:
>>>
>>>>Hi committers and contributors,
>>>>
>>>>I'm sure most of you have ran into this before; whenever I submit a
>>>>code review I'm always curious to find out which reviewers I should
>>>>include that are knowledgeable in that area.
>>>>So I'll typically run git blame to find the last 2-3 people that worked
>>>>on those files, which takes time and may include reviewers no longer
>>>>interested in that code area or miss reviewers that are interested.
>>>>I want to propose a wiki where developers sign up to be reviewers for a
>>>>particular section, could be a feature, directory, etc.
>>>>
>>>>Thoughts?
>>>>
>>>>This allows developers to opt-in to areas of interest (even outside of
>>>>their current expertise), should produce better code reviews, and make
>>>>it easier for new contributors to find the right people.
>>>>
>>>>Thank you,
>>>>Alejandro Fernandez
>>>>
>>>
>
>
Re: Code Review groups
Posted by Sumit Mohanty <sm...@hortonworks.com>.
We can look into the already available component names in the JIRA for the initial list.
We should not create fine-grained groups and aim to have at least 3-5 devs (more is better) in a single component/area.
Possible list:
ambari-web
ambari-views
ambari-server
ambari-agent
stacks-framework/extensibility
stack-definitions (this could break into separate services)
blueprints
alerts/metrics
logsearch
security/kerberos/ldap
stack-upgrade/RU/EU
Once the list is final lets make sure that the available list of components in the JIRA matches this list.
This is probably also a good opportunity to see if there are better alternatives to reviews.apache.org.
regards
Sumit
________________________________________
From: Jayush Luniya <jl...@hortonworks.com>
Sent: Thursday, June 02, 2016 1:47 PM
To: dev@ambari.apache.org
Subject: Re: Code Review groups
+1 on this
On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com> wrote:
>+1. Makes sense.
>
>Thanks.
>
>Regards,
>Swapan.
>
>
>
>
>
>
>
>
>
>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>
>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>>page without letting it get too stale over time.
>>
>>+1
>>
>>Rob
>>
>>
>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com>
>>wrote:
>>
>>>Hi committers and contributors,
>>>
>>>I'm sure most of you have ran into this before; whenever I submit a
>>>code review I'm always curious to find out which reviewers I should
>>>include that are knowledgeable in that area.
>>>So I'll typically run git blame to find the last 2-3 people that worked
>>>on those files, which takes time and may include reviewers no longer
>>>interested in that code area or miss reviewers that are interested.
>>>I want to propose a wiki where developers sign up to be reviewers for a
>>>particular section, could be a feature, directory, etc.
>>>
>>>Thoughts?
>>>
>>>This allows developers to opt-in to areas of interest (even outside of
>>>their current expertise), should produce better code reviews, and make
>>>it easier for new contributors to find the right people.
>>>
>>>Thank you,
>>>Alejandro Fernandez
>>>
>>
Re: Code Review groups
Posted by Jayush Luniya <jl...@hortonworks.com>.
+1 on this
On 6/2/16, 1:44 PM, "Swapan Shridhar" <ss...@hortonworks.com> wrote:
>+1. Makes sense.
>
>Thanks.
>
>Regards,
>Swapan.
>
>
>
>
>
>
>
>
>
>On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>
>>Alejandro, I agree. I just hope we (as a group) can manage the wiki
>>page without letting it get too stale over time.
>>
>>+1
>>
>>Rob
>>
>>
>>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com>
>>wrote:
>>
>>>Hi committers and contributors,
>>>
>>>I'm sure most of you have ran into this before; whenever I submit a
>>>code review I'm always curious to find out which reviewers I should
>>>include that are knowledgeable in that area.
>>>So I'll typically run git blame to find the last 2-3 people that worked
>>>on those files, which takes time and may include reviewers no longer
>>>interested in that code area or miss reviewers that are interested.
>>>I want to propose a wiki where developers sign up to be reviewers for a
>>>particular section, could be a feature, directory, etc.
>>>
>>>Thoughts?
>>>
>>>This allows developers to opt-in to areas of interest (even outside of
>>>their current expertise), should produce better code reviews, and make
>>>it easier for new contributors to find the right people.
>>>
>>>Thank you,
>>>Alejandro Fernandez
>>>
>>
Re: Code Review groups
Posted by Swapan Shridhar <ss...@hortonworks.com>.
+1. Makes sense.
Thanks.
Regards,
Swapan.
On 6/2/16, 1:27 PM, "Robert Levas" <rl...@hortonworks.com> wrote:
>Alejandro, I agree. I just hope we (as a group) can manage the wiki page without letting it get too stale over time.
>
>+1
>
>Rob
>
>
>On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com> wrote:
>
>>Hi committers and contributors,
>>
>>I'm sure most of you have ran into this before; whenever I submit a code review I'm always curious to find out which reviewers I should include that are knowledgeable in that area.
>>So I'll typically run git blame to find the last 2-3 people that worked on those files, which takes time and may include reviewers no longer interested in that code area or miss reviewers that are interested.
>>I want to propose a wiki where developers sign up to be reviewers for a particular section, could be a feature, directory, etc.
>>
>>Thoughts?
>>
>>This allows developers to opt-in to areas of interest (even outside of their current expertise), should produce better code reviews, and make it easier for new contributors to find the right people.
>>
>>Thank you,
>>Alejandro Fernandez
>>
>
Re: Code Review groups
Posted by Robert Levas <rl...@hortonworks.com>.
Alejandro, I agree. I just hope we (as a group) can manage the wiki page without letting it get too stale over time.
+1
Rob
On 6/2/16, 12:55 PM, "Alejandro Fernandez" <af...@hortonworks.com> wrote:
>Hi committers and contributors,
>
>I'm sure most of you have ran into this before; whenever I submit a code review I'm always curious to find out which reviewers I should include that are knowledgeable in that area.
>So I'll typically run git blame to find the last 2-3 people that worked on those files, which takes time and may include reviewers no longer interested in that code area or miss reviewers that are interested.
>I want to propose a wiki where developers sign up to be reviewers for a particular section, could be a feature, directory, etc.
>
>Thoughts?
>
>This allows developers to opt-in to areas of interest (even outside of their current expertise), should produce better code reviews, and make it easier for new contributors to find the right people.
>
>Thank you,
>Alejandro Fernandez
>