On Tuesday 20 September 2005 22:38, [EMAIL PROTECTED] wrote:
> William A. Rowe, Jr. wrote:
> > [EMAIL PROTECTED] 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.
OTOH,
* 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
Yep.
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
