On Fri, Feb 6, 2015 at 6:14 PM, Colin P. McCabe <cmcc...@apache.org> wrote:
> I think it's healthy to have lots of JIRAs that are "patch available." > It means that there is a lot of interest in the project and people > want to contribute. It would be unhealthy if JIRAs that really needed > to get in were not getting in. But beyond a few horror stories, that > usually doesn't seem to happen. > > I agree that we should make an effort to review things that come from > new contributors. I always set aside some time each week to look > through the new JIRAs on the list and review ones that I feel like I > can do. > > I think the "patch manager" for a patch should be the person who > submitted it. As Chris suggested, if nobody is reviewing, email > people who reviewed earlier and ask why. Or email the list and ask if > this is the right approach, and bring attention to the issue. > It is definitely great if contributors could reach out to potential reviewers and follow-up. However, newer contributors find it hard to figure out who to reach out to, and leaving it on them is not very welcoming. Also, people often find one issue, post a fix out of good will and move on. They might not be motivated enough to be the "patch manager" for it. I understand that if it is an important patch, someone else will take it up and get it in. If it is not or if it is duplicated, that JIRA/patch needs to be cleaned up. > > I do like the idea of cleaning up old JIRAs that no longer apply or > that have been abandoned. And perhaps picking up on a few issues that > we have forgotten about. But it is part of release management in my > mind. The release manager decides that we need to get features and > bugfixes X, Y, and Z in release Q, and then pushes on the JIRAs and > committers responsible for making this happen. Since JIRAs implement > features and bugfixes they naturally fall under release management. > This is how several companies that I've worked at have done it > internally... > Getting a release out (for a release manager) is already some work. Adding more responsibilities to the RM (a voluntary role) makes it less enticing. And, distributing the work among multiple workers (with domain knowledge) might be more efficient. > > cheers, > Colin > > On Thu, Feb 5, 2015 at 4:18 PM, Akira AJISAKA > <ajisa...@oss.nttdata.co.jp> wrote: > > I'm thinking it's unhealthy to have over 1000 JIRAs patch available. > > Reviewers should be more welcome and should review patches from > everywhere > > to increase developers and future reviewers. > > > > I'm not completely sure patch managers will make it healthy, however, > > changing the process (and this discussion) would help improving our > > mindsets. > > > > @Committers: Let's review more patches! > > @Developers: You can also review patches you are interested in. Your > > comments will help committers to review and merge them. > > (As you can see, the above comments don't have any enforcement.) > > > > Regards, > > Akira > > > > > > On 2/4/15 13:52, Karthik Kambatla wrote: > >> > >> +1 to patch managers per component. > >> > >> > >> On Wed, Feb 4, 2015 at 12:29 PM, Allen Wittenauer <a...@altiscale.com> > >> wrote: > >> > >>> > >>> Is process really the problem? Or, more directly, how does > any > >>> of > >>> this actually increase the pool beyond the (I’m feeling generous today) > >>> 10 > >>> or so committers (never mind PMC) that actually review patches that > come > >>> from outside their employers on a regular basis? > >>> > >> > >> Process might not be the source of the problem, however process will > help > >> with alleviating the current situation. > >> > >> It would definitely help to increase the number of active committers. > >> Might > >> not be very hard to add committers, but I don't know of a way to make > them > >> active. > >> > >> > >>> > >>> To put this in perspective, there are over 1000 JIRAs in patch > >>> available status across all three projects right now. That’s not even > >>> counting the ones that I know I’ve personally removed the PA status on > >>> because the patch no longer applies... > >>> > >>> > >>> On Feb 4, 2015, at 12:10 PM, Chris Douglas <cdoug...@apache.org> > wrote: > >>> > >>>> Release managers are just committers trying to roll releases; it's not > >>>> an enduring role. A patch manager is just someone helping to track > >>>> work and direct reviewers to issues. The job doesn't come with a hat. > >>>> We could look into a badge and gun if that would help. > >>> > >>> > >> > >> Badge and gun will ensure a single patch-manager per component. > >> > >> > >>>> > >>>> This doesn't require a lot of hand-wringing or diagnosis. If you're > >>>> concerned about the queue, then start trying to find reviewers for > >>>> viable patches. > >>>> > >>>> We should also close issues that require too much work to fix, or at > >>>> least mark them for "Later". Not every idea needs to end in a commit, > >>>> but silence is frustrating for contributors. -C > >>> > >>> > >> > >> +1. > >> > >> > >>>> > >>>> On Wed, Feb 4, 2015 at 10:24 AM, Colin P. McCabe <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 > >>>>> > >>>>> 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? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>> > >>> > >> > >> > > > -- Karthik Kambatla Software Engineer, Cloudera Inc. -------------------------------------------- http://five.sentenc.es
