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