httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Bannert <aa...@clove.org>
Subject Re: the wheel of httpd-dev life is surely slowing down, solutions please
Date Thu, 13 Nov 2003 00:29:06 GMT
On Mon, Nov 10, 2003 at 05:14:35PM -0800, Stas Bekman wrote:
> ======================================================================
> 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.

Would anyone else be in favor of exploring other forms of bug-tracking?
The old system (gnats) was completely email-oriented, which was good
and bad. Bugzilla may be more usable for web-oriented users, but it
it definitely more difficult to use offline (ie. impossible). Perhaps
we could try out the bug tracking system used by the debian project
(http://www.debian.org/Bugs/).

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

I agree with the premise but not your conclusion. Design is being
adversely affected when people make large design-changing commits.
These people should be posting their design changes (code and all)
to the mailing list before committing.

However, if people are making commits and others aren't reviewing
those commits, then the responsibility falls to the reviewer. Nobody
should be obligated to hold on to a patch because other people don't have
the time to review.

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

I have not seen any evidence of this.

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

There is not a fine line between those types of changes that warrant
discussion and those that can be simply committed, so this is a difficult
issue to address.

It is not uncommon for design questions to go unanswered on dev@httpd,
and it has been that way as long as I can remember. Patches, on the other
hand, speak loudest.

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

Make proposals (or better yet, add them to the 2.1 STATUS file. :)

I would personally like to see:

a) httpd.conf rewrite
  - normalized syntax (structured, maybe even *gasp* XML)
  - normalized parsing in apache (defined passes, hooks, restart semantics, etc)
  - other ways to retrieve a config (not just from a file, eg. LDAP)
b) sendfile improvements for 64bit memory addressing machines
   (eg. can we mmap/sendfile a bunch of DVD images at the same time and
    not crash? Do we see improvements?)
c) simplified filters
   (it's been too long since I've thought about this, but basicly writing
    filters is too difficult and should be easier).


> 2d). CRT seemed to come as a replacement for design discussions. It's
> very easy to observe from the traffic numbers:

I think it's actually the opposite. The amount of design discussions in
general has dramatically decreased since RTC went into effect in 2.0.
I recall very few discussions around 2.1 in general.

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

This is a problem that has always plagued Apache (and probably most open
source projects in general). So yes, I agree that it is a problem.

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

-1

Everyone should be encouraged to work on whatever they want, and shouldn't
have to wait for permission from an "owner" to work on their piece.

It's easy to be a champion right now. Take a piece that you think needs
fixing and start committing those fixes. Your changes will be noticed.

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

IMHO that incentive is there right now, but the tools get in the way.

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

That in and of itself is not a problem, in my opinion.


-aaron

Mime
View raw message