Brock Noland 2013-09-04, 12:42
Edward Capriolo 2013-09-04, 16:21
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 <[EMAIL PROTECTED]> wrote:
> I'm not sure I understand what you are saying I see plenty of comments on
> your ticket.
> 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 <[EMAIL PROTECTED]> wrote:
>> 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!!
>> On Tue, Sep 3, 2013 at 1:59 PM, Karl Gierach <[EMAIL PROTECTED]>
>> > 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
>> > 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