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 <[email protected]>: > +1 > > Nice suggestion Alejandro! > > -- > Thanks and Regards, > Aravindan Vijayan > > > > > > > > > On 6/2/16, 11:31 PM, "Gautam Borad" <[email protected]> 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 <[email protected]> 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 <[email protected]>님이 작성: >>> >>> > 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 < >>> > [email protected]> 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" <[email protected]> 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 <[email protected]> >>> > > >Sent: Thursday, June 02, 2016 1:47 PM >>> > > >To: [email protected] >>> > > >Subject: Re: Code Review groups >>> > > > >>> > > >+1 on this >>> > > > >>> > > > >>> > > >On 6/2/16, 1:44 PM, "Swapan Shridhar" <[email protected]> >>> > wrote: >>> > > > >>> > > >>+1. Makes sense. >>> > > >> >>> > > >>Thanks. >>> > > >> >>> > > >>Regards, >>> > > >>Swapan. >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >>On 6/2/16, 1:27 PM, "Robert Levas" <[email protected]> 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" < >>> > [email protected]> >>> > > >>>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.
