One huge plus with Github is that if the official steward of a project would like to hand it off to someone else, or is failing to maintain it, it is trivial for someone else to take over the project.
One huge plus with Github is that if the official steward of a project would like to hand it off to someone else, or is failing to maintain it, it is trivial for someone else to take over the project.
As you say it's trivial to someone to take over the project and maintain it but not trivial to anyone to find the right fork of the project when a project has 100+ forks.
If the maintainers really aren't doing what they volunteered to do, then volunteer yourself and get it done.
You're answering a question I'm not even remotely asking.
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.
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.
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.
The GitHub layout is really telling of the new open source philosophy. They put the code front and center (main page), and right above it show you with first class status all the bugs it has (issues link) as well as all the proposed changes (pull requests link).
Git => designed for forking and reintegrating.
Subversion => fucking painful for either.
I find it ironic that your first post complains that the author is comparing ASF to a sand box, but then you go and suggest that GP should just fork a project. I think you really are missing the point: sandboxing is a bunch of people just forking. A community is when those forks are then cherry picked and re-integrated. Subversion is shit at that. Git is awesome.
I have no skin in this game, but if I were to look at the requirements as you describe them, I'd recommend using git and think you were crazy to use subversion.
No. That's not how open source works.