hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: Patch review process
Date Wed, 04 Feb 2015 20:02:30 GMT
The main JIRA dashboard for each project has an Issues tab with useful
summary statistics and links to filtered queries, most notably links to
unresolved issues grouped by each project sub-component.





I can see that many of these represent a much smaller, more manageable
work queue than trying to sift through all patch available, or worse yet,
all unresolved.  For example, here are the results for Hadoop Common
native, HDFS snapshots, MapReduce Job History Server, and YARN Capacity





Suppose we ask for committers to act in the Patch Manager role associated
with these per-component queries as their work queues.  If people are
working in an area of expertise, then they'll likely process the queue
efficiently.  If people want to stretch into an area of code where they
are less familiar, then volunteering as Patch Manager could be a way to
ramp up.

The success of this approach would depend on the quality of our JIRA
metadata.  We¹d need to be diligent about assigning each issue to its
correct component.  We may also find a need to restructure the component
breakdown over time.  Right now, it tends to mirror our Java package
structure pretty closely, but something like ³namenode" is quite broad as
a patch queue.


Chris Nauroth

On 2/4/15, 11:14 AM, "Steve Loughran" <stevel@hortonworks.com> wrote:

>I'm worrying more about the ongoing situation. As a release approaches
>someone effectively goes full time as the gatekeeper, -for a good release
>they should be saying "too late!" for most features and "only if it's low
>risk" to non-critical bug fixes
>Which means that non-critical stuff don't get in as a release approaches.
>This is a good thing for release stability, but not for getting work in.
>Active patch queue management should be something going on when the
>releases aren't being made (or even then, just not near the release
>The problem is it takes time and effort. Time to review the code, test
>it, maybe even tune it a bit to help.
>For the big bits of work, if you can get full-time/part time support from
>committers then you do stand a chance of getting it in. But the effort
>needed for those project usually means that the engineer in question has
>been allocated that time by their employer. If its a big project and they
>don't have that support, I think the patch is going to be in trouble. The
>new NFS client proposal is an example of that: I can personally see why
>it'd be nice to have, but I'm not going to go  near it.
>For the little bits of work, they take less continuous time and effort,
>but someone who understands the area in question does need to go through
>them, provide feedback and help get them in.
>I don't think we do enough there. I understand why not: time and effort,
>but think we miss out in the process.
>On 4 February 2015 at 18:25:05, Colin P. McCabe
>(cmccabe@apache.org<mailto:cmccabe@apache.org>) wrote:
>I wonder if this work logically falls under the release manager role.
>During a release, we generally spend a little bit of time thinking
>about what new features we added, systems we stabilized, interfaces we
>changed, etc. etc. This gives us some perspective to look backwards
>at old JIRAs and either close them as no longer relevant, or target
>them for the next release (with appropriate encouragement to the
>people who might have the expertise to make that happen.)

View raw message