httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Kew <>
Subject Re: Issues for 2.1.8
Date Tue, 20 Sep 2005 22:27:54 GMT
On Tuesday 20 September 2005 22:38, wrote:
> William A. Rowe, Jr. wrote:
> > wrote:
> [..cut..]
> > I'd argue the opposite.  Do you notice how few people at any given time
> > are following bugzilla?  Cleaning up and mopping up?  I've done my 400+
> > hours of time on that side, and am likely to jump back in from time to
> > time, but it's unfair to throw unstable code out into the general (read:
> I know that this is a problem and for sure I have to admit that I should
> do more on PR's. I think everybody appreciates your efforts
> on the bugzilla frontier here. So some honest question (I really don't know
> the answer): From your experience in the past: Is the number of PR's for
> experimental modules that have not been handled by the driver(s) of these
> modules remarkably higher than for other parts of httpd?

The highest numbers of bugs are for the more complex subsystems.
For example, cache, ldap, ssl, proxy - which are NOT currently in 
experimental.  Regarding the new modules, there are some bug
reports which mod_filter solves, but AFAIK none for mod_filter itself,
nor for mod_dbd or mod_charset_lite (bugzilla is timing out right now,
so I can't check).

We should prune out things that are unmaintained - especially perchild -
but not things that are new.

> If yes, then these module shouldn't be in the experimental section of a
> stable branch.
> > non-developer) community and have it all land on the backs of five folk
> > who may or may not be interested in that specific flakey module.
> I understand your concerns and I know that users are sometimes the way:
> "Hey its in the stable release, so it should work and I want it to be
> fixed".

That's the story of perchild.  And was the story of cache for a long, long 
time, before people got around to doing some serious hacking.

> And as I mentioned special care must be taken to decide which 
> modules can remain in the experimental section of a stable branch and which
> not. Of course the driver(s) of these modules should remain commited to
> handle the PR's and patches coming in. Furthermore the module should have a
> minimum level of quality. I know these are very "soft" definitions from my
> side and that is a weak spot.

So taking the useful modules currently marked /experimental/

  * mod_charset_lite has been there a long time.  It could use more work
    (configuration is very limiting) but is useful within its limitations.
  * mod_filter has been there a while and got some positive feedback.
     But since it's only in 2.1 (or 2.0+power-user-hack), that's limited.
  * Event MPM - similar situation to mod_filter.
  * mod_dbd is new but is going to be Big and Important :-)  And it's   
    descended from a family of modules that have been in production
    for a couple of years.


  * perchild keeps on going nowhere and should be removed until and
    unless something happens.

> > It got fixed not because there were more testers, but as often as not,
> > because there were developers who -cared-.  So, if those same developers
> Of course they got fixed because developers cared and did good work. But
> they also got better because people used them, found bugs (some resulting
> in PR's, some in patches), edge cases and proposed new features. So you
> need both sides


Please lets bear in mind that a lot of code marked stable is really just as
new and untested, and going through the same process.  Obvious cases:
proxy, cache and ldap have been hugely re-hacked since anything in 2.0.

Nick Kew

View raw message