I believe Sander's suggested that we start a patch manager role (discussion at AC Hackathon!). A few other projects I'm involved with do this. It'd be goodness, I think. But, the problem is finding a volunteer willing to shepherd patches.
-1
Creating roles like this is just as bad as having chunks of httpd "owned" by one particular developer. (See below)
I don't think you understand the role of 'patch manager.' On the projects I'm involved with, that person's only responsibility is for ensuring that the patches posted to the mailing list are entered into the right tool.
I think that can easily be a volunteer, rotating job as you don't need to do anything more than that.
How is this different than "owners" above? You can't expect developers on this list to think ahead of time when they might have extra time to contribute to this project. Most of the time it is on a whim late at night when all of the important chores are taken care of. If you ask for people to sign up for a slotted amount of time, you'll only end up excluding people who don't work on Apache at their day job.
In the patch manager role, nothing would preclude others from adding patches to the right tool. But, having someone whose responsibility it is to ensure that patches get inputted into the tool on a timely basis is goodness. On other projects I'm involved with, that person isn't an even a committer. They don't have to understand what the patch does - just make sure it is recorded and allow for annotation.
And, it doesn't have to be on a 'timely' basis - once a week, you go through and ensure that all [PATCH] messages are in the right patch management tool. This lessens the number of dropped patches that we'd have. (Bugzilla sucks at this, so I think we'd need a new tool.)
Woah woah woah. Are you discouraging people from thinking about big changes for the 2.2 timeframe? If someone has a revolutionary idea for the next generation of Apache HTTPD, who will stand in their way? Not I.
Frankly, yes.
I think our changes that we already have in the tree is about 'right' for 2.2 (no big architecture changes, but lots of modules have been rewritten and improved). It's just that no one has time or desire to shepherd 2.2 to a release. And, I think we need APR 1.0 out the door before 2.2 can be rationally discussed.
If we did any major changes from this point that require modules to rewrite themselves, we'd need to go to 3.0 per our versioning rules. And, I'd *strongly* discourage that. I don't think it's in anyone's best interest to revamp our architecture at this stage.
We don't need to give a moving target to our poor module developers. Only by producing a series of high-quality releases can we ensure that module writers will be confident in writing against 2.0 or 2.2. If we come out with 3.x now, I think we'll just end up hurting ourselves in the long run even worse than we are now. -- justin
