Re: HIVE-5104 patch status?
Hi, Looks like your patch has been committed, but I just wanted to confirm for those lurking. If you have a patch up on a JIRA, emailing the dev list is one of the correct ways of engaging a committer. IRC is also a viable strategy. Thanks for your contribution!! Cheers, Brock On Tue, Sep 3, 2013 at 1:59 PM, Karl Gierach k...@sourcethought.com wrote: Hi, We at Sourcethought have contributed at patch to fix JIRA issue HIVE-5104 about 2 weeks back, although it appears that this patch has not received any comments. The patch is relevant for the both github Hive branch-0.11 and the trunk, as both source files were not changed since the 0.11 branch was created. What steps need to be taken to incorporate this patch into the next release? Do we need to request approval from a committer? Best Regards, Karl Gierach Lead Engineer SourceThought, Inc. -- Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org
Re: HIVE-5104 patch status?
I'm not sure I understand what you are saying I see plenty of comments on your ticket. http://www.apache.org/dev/committers.html#committer-responsibilities Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. Helping users Committers should monitor both the dev and user lists for the projects that they work on and (collectively) provide prompt and useful responses to questions from users. Monitoring commits and issues Committers should review commit email messages for their projects and point out anything that looks funny or that may bring in IP issues. Monitoring Bugzilla / Jira for bugs or enhancement requests is also a responsibility of Committers. Generally we (committers pmc) attempt to wade though the open jira issues and review and commit open issues. Not all of us are full time, and not all of us specialize across the entire code base, so the length of time a patch can stay out there is variable. My process is this: Review jira for things marked PATCH AVAILABLE If I understand the scope of the issue I review it and leave comments. If ready I wait for the test and then commit. I personally try to maintain a balance of 75% writing code 25% review but lately I am about 80% review 20% code. I would like us to move to a road map and feature based releases with smaller tuck-in issues. At the moment everything that flows into our jira looks the same to me as we have people going into several different directions, it makes it fairly hard to order the incoming issues in priority. On Wed, Sep 4, 2013 at 8:42 AM, Brock Noland br...@cloudera.com wrote: Hi, Looks like your patch has been committed, but I just wanted to confirm for those lurking. If you have a patch up on a JIRA, emailing the dev list is one of the correct ways of engaging a committer. IRC is also a viable strategy. Thanks for your contribution!! Cheers, Brock On Tue, Sep 3, 2013 at 1:59 PM, Karl Gierach k...@sourcethought.com wrote: Hi, We at Sourcethought have contributed at patch to fix JIRA issue HIVE-5104 about 2 weeks back, although it appears that this patch has not received any comments. The patch is relevant for the both github Hive branch-0.11 and the trunk, as both source files were not changed since the 0.11 branch was created. What steps need to be taken to incorporate this patch into the next release? Do we need to request approval from a committer? Best Regards, Karl Gierach Lead Engineer SourceThought, Inc. -- Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org
Re: HIVE-5104 patch status?
Hi Karl, Looks like we crossed streams. :) I started reviewing your patch last thursday, and committed it yesterday. I had to run some tests before incorporating your patch. I did initially comment up asking for patch regeneration since your patch did not apply cleanly for me on trunk, and also had some whitespacing errors, but I decided to go ahead and tidy up the patch to apply instead of holding you up. Since 0.11 has been released, unless it's an important bugfix, or unless we do a re-release of 0.11, we would not be applying it on that branch. In this case, since it's more akin to a feature introduction, it should be part of our next 0.12 release. Thanks for your contribution! On Wed, Sep 4, 2013 at 9:21 AM, Edward Capriolo edlinuxg...@gmail.com wrote: I'm not sure I understand what you are saying I see plenty of comments on your ticket. http://www.apache.org/dev/committers.html#committer-responsibilities Applying patches In order to grow and maintain healthy communities, committers need to discuss, review and apply patches submitted by volunteers. The Committers are also responsible for the quality and IP clearance of the code that goes into ASF repositories. Helping users Committers should monitor both the dev and user lists for the projects that they work on and (collectively) provide prompt and useful responses to questions from users. Monitoring commits and issues Committers should review commit email messages for their projects and point out anything that looks funny or that may bring in IP issues. Monitoring Bugzilla / Jira for bugs or enhancement requests is also a responsibility of Committers. Generally we (committers pmc) attempt to wade though the open jira issues and review and commit open issues. Not all of us are full time, and not all of us specialize across the entire code base, so the length of time a patch can stay out there is variable. My process is this: Review jira for things marked PATCH AVAILABLE If I understand the scope of the issue I review it and leave comments. If ready I wait for the test and then commit. I personally try to maintain a balance of 75% writing code 25% review but lately I am about 80% review 20% code. I would like us to move to a road map and feature based releases with smaller tuck-in issues. At the moment everything that flows into our jira looks the same to me as we have people going into several different directions, it makes it fairly hard to order the incoming issues in priority. On Wed, Sep 4, 2013 at 8:42 AM, Brock Noland br...@cloudera.com wrote: Hi, Looks like your patch has been committed, but I just wanted to confirm for those lurking. If you have a patch up on a JIRA, emailing the dev list is one of the correct ways of engaging a committer. IRC is also a viable strategy. Thanks for your contribution!! Cheers, Brock On Tue, Sep 3, 2013 at 1:59 PM, Karl Gierach k...@sourcethought.com wrote: Hi, We at Sourcethought have contributed at patch to fix JIRA issue HIVE-5104 about 2 weeks back, although it appears that this patch has not received any comments. The patch is relevant for the both github Hive branch-0.11 and the trunk, as both source files were not changed since the 0.11 branch was created. What steps need to be taken to incorporate this patch into the next release? Do we need to request approval from a committer? Best Regards, Karl Gierach Lead Engineer SourceThought, Inc. -- Apache MRUnit - Unit testing MapReduce - http://mrunit.apache.org
