If you're using git, as the OP suggets, then you're going to fork it just to work on it. Forking isn't dramatic. Code is open source for a reason. If you have a critical bug in code you need running in your infrastructure, take ownership of it and fork it. Then do the dirty work to get the patch pushed back up stream.
If the maintainers really aren't doing what they volunteered to do, then volunteer yourself and get it done.
There isn't One Answer. The point is, you have plenty of alternatives. I don't know why the patch hasn't been applied. I know how I can find out though: I can join the developer mailing list and ask. If that doesn't work, I can track down a developer directly (they're not hard to find once you're on the mailing list) and bug 'em until I get a decent response. If it's clear the maintainers aren't doing their job, raise hell on the mailing lists and push to become a committer yourself so you can do the job right.
While that's happening, you can take the approach of maintaining your own patches so that you're not beholden to anyone in particular.
The whole point of open source is empowerment, not entitlement. No one is entitled to get any bug fixed. It's great when it happens but ultimately, everyone is empowered to make things happen themselves.
So you do agree that there are options beyond forking it or merely "raising a ruckus on the mailing list". My point was precisely that there are additional answers and that just glibly saying "Well, just fork it or accept what the mailing list result is" isn't a good summary of the alternatives, and in the context of what you were replying to borders on deceptive.
In the meantime, the fact that I am rich with options doesn't negate the original discussion, which is that the Apache processes are becoming distinctly suboptimal for the context they work in. The fact that I can just take the software and run with it doesn't fix their processes, and the fact that anybody can do so doesn't excuse broken processes. The fact that we can fork does not mean everybody should just stop discussing Apache processes; it doesn't follow.
I'm still in context: "I was was almost driven to start blogging last week by ASF's poor job of maintaining its projects. There was a small bug in Solr. I was not the first to find this bug, and someone had not only reported the bug, but filed a patch on the bug tracker a year and a half ago. The patch was never merged in, nobody provided any feedback as to why the patch wasn't merged in." "You can just fork it" is not an answer to this problem. I'd say in its own way it's a disguised confession that in fact the problems with the project are indeed so bad that your only hope is to fork it yourself. Well, that still says bad things about the project, regardless of whether I have mitigation options.
Because you act as if a "fork" is a drastic choice, when the reply calmly explained that "fork" doesn't have to mean "hey, let's create a new project and try to poach users into abandoning the original one".
The answers seems to be frank, and based on having absolutely no knowledge of Apache, maybe an appropriate one. It seems like they have a process that works for them, and they are quite interested in continuing with it. And that's fine. For people who want a more (for the lack of a more succinct way of expressing it) Git/GitHub style project, they can fork it and hack away to their hearts content.
That doesn't preclude upstream adoption of code, and it doesn't preclude discussions of improved workflow within ASF.
If the maintainers really aren't doing what they volunteered to do, then volunteer yourself and get it done.