+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.
