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.
https://issues.apache.org/jira/browse/HADOOP/?selectedTab=com.atlassian.jir a.jira-projects-plugin:issues-panel https://issues.apache.org/jira/browse/HDFS/?selectedTab=com.atlassian.jira. jira-projects-plugin:issues-panel https://issues.apache.org/jira/browse/MAPREDUCE/?selectedTab=com.atlassian. jira.jira-projects-plugin:issues-panel https://issues.apache.org/jira/browse/YARN/?selectedTab=com.atlassian.jira. jira-projects-plugin:issues-panel 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 Scheduler. https://issues.apache.org/jira/issues/?jql=project%20%3D%20HADOOP%20AND%20r esolution%20%3D%20Unresolved%20AND%20component%20%3D%20native%20ORDER%20BY% 20priority%20DESC https://issues.apache.org/jira/issues/?jql=project%20%3D%20HDFS%20AND%20res olution%20%3D%20Unresolved%20AND%20component%20%3D%20snapshots%20ORDER%20BY %20priority%20DESC https://issues.apache.org/jira/issues/?jql=project%20%3D%20MAPREDUCE%20AND% 20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20jobhistoryserver% 20ORDER%20BY%20priority%20DESC https://issues.apache.org/jira/issues/?jql=project%20%3D%20YARN%20AND%20res olution%20%3D%20Unresolved%20AND%20component%20%3D%20capacityscheduler%20OR DER%20BY%20priority%20DESC 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. Thoughts? Chris Nauroth Hortonworks http://hortonworks.com/ On 2/4/15, 11:14 AM, "Steve Loughran" <ste...@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 >branch). > >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 >(cmcc...@apache.org<mailto:cmcc...@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.) > >best, >Colin
