ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jungtaek Lim <kabh...@gmail.com>
Subject Re: Code Review groups
Date Fri, 03 Jun 2016 02:16:40 GMT
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 <mithmatt@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" <smohanty@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 <jluniya@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" <sshridhar@hortonworks.com>
> wrote:
> > >
> > >>+1. Makes sense.
> > >>
> > >>Thanks.
> > >>
> > >>Regards,
> > >>Swapan.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>On 6/2/16, 1:27 PM, "Robert Levas" <rlevas@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/
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message