1) Bugs
searching for NEW and REOPENED bugs in httpd-2.0 returns: 420 entries
http://nagoya.apache.org/bugzilla/buglist.cgi?bug_status=NEW&bug_status=REOPENED&product=Apache+httpd-2.0
yes, far too many :(
Suggestion: make bugzilla CC bug-reports to the dev list. Most developers won't just go and check the bugs database to see if there is something to fix, both because they don't have time and because there are too many things to fix. Posting the reports to the list raises a chance for the developer to have a free minute and may be to resolve the bug immediately or close it.
That would reduce the number of subscribers to dev@, which is the opposite of what we need. At least we have a monthy summary posted to dev@ which reminds folks that there is a bug db. Also, it is my interpretation of bug db traffic that Joshua and Andre' already jump on the PRs that can be resolved immediately. Many of the outstanding PRs are quite difficult to resolve.
Working the bug db is a noble effort, but many in our community have no time to work it. The way to get more time being spent on the bug db is to take the kind of actions that increase the number of httpd developers.
2) Lack of Design
2a). Design of new on-going features (and changes/fixes) of the existing features is not discussed before it's put to the code. When it's committed it's usually too late to have any incentive to give a design feedback, after all it's already working and we are too busy with other things, so whatever.
We leave it up to the developer to judge whether some design issue needs to be discussed first. If something is committed prior to being discussed, then the person with the objection must start the discussion at that point. This is a tool against stagnation. If somebody has the time/energy to work on something, we can't put up a roadblock just because nobody else has the time/skills to discuss it with them. The only roadblock is the one to protect users of stable releases.
The worst part is that it's now easy to sneak in code which otherwise would never be accepted (and backport it to 2.0). I don't have any examples, but I think the danger is there.
There is a barrier to getting things backported to 2.0 as a protection against possible drawbacks of C-T-R.
If three people are in favor of putting something in the stable branch, mistakes can still happen, but I don't see how we can refer to such a backport as sneaking in code.
2b). As a side-effect when someone asks a design question (e.g. me) it's not being answered because people tell: we are in the CRT mode, go ahead code it and commit it. But if the poster doesn't know what's the right design, if she did she won't have asked in first place.
Alternate opinion: If a question is not answered, it is because nobody has time/skills.
As mentioned above, I see the C-T-R mode for 2.1-dev as a tool that helps work-around a lack of energy/skills on the list.
2c). Future design. There is no clear roadmap of where do we go with Apache 2.1. People scratch their itches with new ideas which is cool, but if there was a plan to work on things, this may have invited new developers to scratch their itches.
2d). CRT seemed to come as a replacement for design discussions. It's very easy to observe from the traffic numbers:
As Bill said, it has been this way for some time. At some point we created a stable branch for 2.0-dev, but 2.1-dev is handled in the same way that 2.x was handled all along.
3). Contributions
I don't have numbers to support my clause, but I have a strong feeling that nowadays we see a much smaller number of posts with contributions from non-developers
I can believe it.
Solutions:
a. certain (most?) chunks of httpd lack owners. If httpd was to have clear owners of certain code bases then it'll be easy to take care of bug reports and contributions/patches. Even though httpd is collectively owned, it doesn't preclude champions in certain areas, who can see that good things happen to the areas they overlook.
b. similar to the root rotation we have on the infrastructure, I suggest to have a voluntary weekly rotation of httpd-dev list champion whose responsibility is to make sure that most (all?) bug-reports and contributions are dealts with: assigned to those who those champions who know how to fix/review/adopt things (See (a) above), asking for more input if needed, etc. You don't have to know httpd as your five fingers to be able to do a great rewarding job.
Personally I'm very disinterested in a system that puts certain responsibility on a single person for an area of the code or for a period of time. Work/life issues arise from time to time that force folks to disappear for a stretch. To the greatest extent possible, any policies/procedures we have should have the goal of channelling volunteer efforts instead of placing certain responsibilities with a single person.
It would be good to have a single place other than the mailing list (2.1-dev STATUS or bug db or something else) where patches are tracked and where contributors can know the status. Somebody brought up the idea of "patch manager." I'm interested in hearing more about that. Anything that focuses the available light on these contributions would be very helpful.
3a) I can hardly see new developers joining the team, should we blame the economy or the lack of encouragement for people to contribute.
perhaps some of both... One of these we can't take action on anyway. All we can try to do is be gracious with contributions. Sooner or later that will result in new people devoting significant time to httpd.
> 4). Feedback Preference and List Karma
Without agreeing or disagreeing with anything you wrote here, I'm not sure what possible actions could be. Any action should be consistent with the idea that httpd developers are all volunteers and any effort they are able to make is to be valued. But it doesn't bring a healthy community to finish with saying
* If an httpd developer is only interested in 2.1-dev, so what?
* If an httpd developer is only interested in a certain functional area of the code, so what?
* If an httpd developer ignores the bug db, so what?
* If an httpd developer ignores dev@ posts that they don't think is something for httpd to worry about, so what?
Somehow as a group we have to help new folks who are willing to do the work to fix/enhance httpd in a way that is beneficial to others. Having a better way to track patches and make sure that would-be contributers get feedback is a step in the right direction.
