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
