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, "田中正浩" <[email protected]> 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 <[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. >
