I have several reasons to believe that the wheel of httpd-dev life is slowing down and something has to be done to get this wheel up to the speed like in the good old days. The following observation are listed in no particular order. I've also tried to offer suggestions how to resolve problems.
====================================================================== 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
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.
====================================================================== 2) Lack of Design
In my personal opinion, the move to CTR from RTC had very bad implications on the design of httpd 2.1.
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.
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.
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.
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:
http://marc.theaimsgroup.com/?l=apache-httpd-dev 2003-11-01 - 2003-12-01 (118 messages) 2003-10-01 - 2003-11-01 (336 messages) 2003-09-01 - 2003-10-01 (275 messages) 2003-08-01 - 2003-09-01 (264 messages) 2003-07-01 - 2003-08-01 (321 messages) 2003-06-01 - 2003-07-01 (430 messages) 2003-05-01 - 2003-06-01 (450 messages) 2003-04-01 - 2003-05-01 (359 messages) 2003-03-01 - 2003-04-01 (696 messages) 2003-02-01 - 2003-03-01 (573 messages) 2003-01-01 - 2003-02-01 (546 messages) 2002-12-01 - 2003-01-01 (436 messages) 2002-11-01 - 2002-12-01 (538 messages) 2002-10-01 - 2002-11-01 (763 messages) 2002-09-01 - 2002-10-01 (894 messages) 2002-08-01 - 2002-09-01 (815 messages) 2002-07-01 - 2002-08-01 (721 messages) 2002-06-01 - 2002-07-01 (916 messages) 2002-05-01 - 2002-06-01 (1028 messages) 2002-04-01 - 2002-05-01 (1380 messages) 2002-03-01 - 2002-04-01 (1094 messages) 2002-02-01 - 2002-03-01 (1155 messages)
Quiz: based on this input, tell which date CRT was introduced at.
You don't need a fancy graph to see a clear decline in the last 1.5 years. Quite a few people suggested that this is due to the market decline. I won't doubt them, but it's quite possible that the market hasn't changed to the worst in the last 1.5 years (it is more likely that we should have seen this dip in 2001-2002, which I can't see from the numbers at the above URL).
The cvs commit average rate hasn't changed much, which shows that development continues though mainly behind the scenes. http://marc.theaimsgroup.com/?l=apache-cvs&r=1&w=2
====================================================================== 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, since most contributions are simply ignored and it's a known thing among Apache community that posting fixes and suggestions to httpd-dev list is usually a waste of time. (This is based on my personal experience and discussions with other developers who aren't httpd-core coders). I realize that I'm not entirely correct saying that, since some things are picked up, so I apologize to those folks who do try hard to pick those things.
The obvious problem is that most of those things are unsexy, usually don't fit someones itch and they sometimes require a lot of communication overhead with the reporter/contributor just to understand what exactly is going on.
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.
c. turn the dealing with contributions and bugs into a sexy thing. Everybody wants to feed their ego, there is no better way to make your ego happy then getting a positive feedback from a person you have helped to resolve a bug or handhold to provide a good patch for the new feature, they spent so much time working on.
3a) I can hardly see new developers joining the team, should we blame the economy or the lack of encouragement for people to contribute. I think we now have a higher rate of developers who leave the project (even though that technically they are still committers and all) the those who join the project. Which obviously has clear effects on the productivity of the dev list.
====================================================================== 4). Feedback Preference and List Karma
List Karma is a known issue in all Open Source projects. It's obvious that known and respected members of the httpd-dev list come to a higher preference when it comes to posting feedback and any answers at all. It's very easy to see that questions from most known httpd developers almost always have a long thread with resolution. Other posters are usually lucky to get any responses at all, and if they do usually the thread would die out without any resolutions.
I'm not questioning the validity of the list karma, this is something that I happen to stick to myself on the lists where I can give useful feedback: I usually answer first questions from people whom I know for good and bad. What I want to talk about is about the karma of the posters who don't ask to solve their "personal" problems, but act on behalf sub-projects built upon httpd. These posters try to solve a problem for hundreds, thousands and sometimes millions of people, who won't use Apache at all if they all they needed is to serve static pages -- there are several other web servers which outperform Apache on this front. They use Apache because of the 3rd party modules that build upon Apache. It's those 3rd party modules that Apache should be thankful to to its current world domination in the web server sector.
Therefore I think httpd developers should stop thinking, "this poster's question is not httpd's problem, I have better things to do". I'd like to suggest that it's a very own httpd problem, because usually you get questions from 3rd party developers when something in httpd doesn't cooperate with those 3rd party modules and needs to be fixed. I think it's much less important to work on Apache 2.1 and much more important to polish 2.0 and make 3rd party developers happy. (wearing the 3rd party module developer hat) we don't need no Apache 2.1 in the sky, we need Apache 2.0 on steady on the ground, so we can run our modules on.
and if I may add that giving those 3rd party developers a commit access is not a solution to the problem, because they hardly survive coping with their own projects' bugs, support issues and feature demands. So telling them: "hey, we gave you a commit access, just go and code/fix it". is not always working.
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
