httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject the wheel of httpd-dev life is surely slowing down, solutions please
Date Tue, 11 Nov 2003 01:14:35 GMT
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

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:
     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.

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.


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     mod_perl Guide --->

View raw message