At 07:14 PM 11/10/2003, Stas Bekman wrote:
>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
>
