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 On Mon, Feb 2, 2015 at 2:03 PM, Mai Haohui <ricet...@gmail.com> wrote: > +1 on the idea of patch managers. As the patch managers should have > good expertise on the specific fields, they are more productive on > reviewing the patches and driving the development on the specific > fields forward. > > > ~Haohui > > On Mon, Feb 2, 2015 at 12:55 PM, Chris Nauroth <cnaur...@hortonworks.com> > wrote: >> I like the idea of patch managers monitoring specific queues of issues, >> perhaps implemented as a set of jira filters on different values for the >> component or label fields. Right now, looking at the whole HADOOP backlog >> is daunting. Using separate filtered review queues could help each >> reviewer focus and parallelize the work. >> >> Going back to the topic of tooling, I just learned that multiple Apache >> projects have expressed interest in Gerrit recently. I've never used >> Gerrit and so can¹t speak in favor or against it, but I think consistency >> across Apache has benefits. Issue INFRA-2205 has the discussion. The >> issue is closed, but there is recent discussion in the comments. >> >> https://issues.apache.org/jira/browse/INFRA-2205 >> >> >> Chris Nauroth >> Hortonworks >> http://hortonworks.com/ >> >> >> >> >> >> >> On 2/2/15, 3:56 AM, "Chris Douglas" <cdoug...@apache.org> wrote: >> >>>Many projects have unofficial "patch managers": >>> >>>http://cp.mcafee.com/d/avndxMs73gsrhojju7f9TsdTdETsuK-MOOMrhKUqem76kkkPqdT >>>7HLIcILCQrK6zB5ByVEVKrJ3mURCj1heIpRwoH4HjBPpeIpRwoH4HjBPvKLKeSovW_8ELfK6zB >>>zHTbFICzBPAQrICzBNXBHFShhlKCNOEuvkzaT0QSyrhdTVeZXTLuZXCXCM0qQqEdSB0zmBenPU >>>pgDIvbGX3ifG_2v0U35JDoCnlS6AvyrnlH0KxVAL7VJNwnu7cLCzALq6JNHcCsjH6to6aNaQVs >>>54ZgHlrJmSNf-00CS4QSjobZ8Qg1rpS9Cy2fCpuod42QqS-B3qr1LpPX92TieQHh >>> >>>People who go through outstanding issues, ensuring that each has >>>reached a stable state, or at least a willing reviewer. -C >>> >>>On Mon, Feb 2, 2015 at 3:45 AM, Steve Loughran <ste...@hortonworks.com> >>>wrote: >>>> >>>> Given experience of apache reviews, I don't know how much time to spend >>>>on it. I'm curious about Gerrit, but again, if JIRA integration is what >>>>is sought, Cruicible sounds better. >>>> >>>> Returning to other issues in the discussion >>>> >>>> 1. Improving test times would make a big difference; locally as well as >>>>on Jira. >>>> >>>> 2. How can we clear through today's backlog without relying on a future >>>>piece of technology from magically fixing it? >>>> >>>> For clearing the backlog, I don't see any solution other than "people >>>>put in time". I know its an obligation for committers to do this, but I >>>>also know how little time most of us have to do things other than deal >>>>with our own tests failing. As a result, things that aren't viewed as >>>>critical get neglected. Shell, build, object stores, cruft cleanup, etc, >>>>I think people that care about these areas are going to have to get >>>>together and sync up. For some of the stuff it may be quite fast ‹people >>>>may not have noticed, but a few of us have brought the build >>>>dependencies forward fairly fast recently, with a goal of Hadoop >>>>branch-2/trunk being compatible with recent Guava versions and java 8. >>>> >>>> I've been doing some S3/object store work the last couple of weekends; >>>>that's slow as test runs take 30+ minutes against the far end, test runs >>>>jenkins doesn't do. If anyone else wants to look at the fs/s3 and >>>>fs/swift queue their input is welcome. >>>> >>>> And of course AW went through the entire backlog of shell stuff & a lot >>>>of the not-in-branch-2 features. >>>> >>>> So where now? What is a strategy to deal with all those things in the >>>>queue? >>>> >>>> >>>> >>>> >>
