On 7 February 2015 at 02:14:39, Colin P. McCabe (cmcc...@apache.org<mailto: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 believe it is easier for you or I to assert that than it is for someone to submit a patch which really matters to them, only to find it languishes ignored, because it doesn't appear to matter to anyone who has the rights to get it into the code. 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. Is the fact that you have keep asking people to look at your patch a good one? Its certainly a sign that the submitter feels it matters, but it also shows there's no active queue management, I suspect it also tends to be easier to pull off if you are already known in the community. I know a certain AW will now note that it helps to share employers with other committers, but we also tend to review and +1 code work by people you already know and are reasonably good at working with. (i.e you don't fear their code, trust them to care about issues like compatibility, testing, etc). Certainly I appreciate Alan's +1s for my languishing patches. If you aren't known, if you have just one patch which appears to only surface in your env, risk of neglect. example: https://issues.apache.org/jira/browse/HADOOP-3426 "Datanode does not start up if the local machines DNS isn't working right and dfs.datanode.dns.interface==default" my home lan, my broken /etc/resolv.conf, my patch. And until in Hadoop: my private branch needed to work. And now its in, I'm happy with that specific problem being addressed. Except, there's one nearby about failing better in an IPv6 world, that's been around for a while and nobody has looked at https://issues.apache.org/jira/browse/HADOOP-3619 It's little ones like that that I think can fall by the wayside (I'm looking at it now). Here's someone pushing the boundaries: running without IPv6 disabled -and instead of us picking up the early lessons, they are being ignored unless/until they become issues in the runup to a release. And, we are trying to be a community here, which means encouraging more contributions. Those of us working full time on it should be able to allocate some time, even if only weekends outside the release phase, to catching up with the work queue. There's an article here that makes this point —that OSS projects should be inclusive, not exclusive, which means encouraging a more diverse set of contributors. http://www.curiousefficiency.org/posts/2015/01/abuse-is-not-ok.html We can't do that if we restrict our reviews to work by known people, The other issue I find with the "harass people until they commit it" strategy is that it scales badly. Not just from the # of people submitting patches, but from the #of patches. If I have a small 4 line patch, is it worth the effort of chasing people round to get it in, or should I save my effort for the more transformational patches? Furthermore, as a recipient of such emails, after I while I get more ruthless about ignoring them. Though I think I'll look at a few today, including one that colleague of Colin's has been asking for (HADOOP-11293), as I feel sorry for anyone attempting a minor-but-widereaching bit of code cleanup. 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. +1 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... At release time it's too late to do things that are important yet whose roll-out is considered a threat to the code. If you were to look at the history of any JIRA related to updating Jetty you can see this: we know the problems, but don't want to go there, especially near a release time. And, given the stress induced by the "great protobuf upgrade of 2013", I agree. Except now its not release time, nobody has gone near Jetty again. Anyway, I'm going to review some patches this weekend. Please DO NOT email suggestions to me, as that will only re-inforce the "email-priority-scheduler" algorithm I have just argued against. I will pick some minor ones from people with little or no contribution history, or ones that I care about but have forgotten to review. -Steve
