Nick Kew wrote:
The highest numbers of bugs are for the more complex subsystems.
For example, cache, ldap, ssl, proxy - which are NOT currently in
experimental.
Whoa...
* cache - that's experimental.
* ldap - that's experimental.
* proxy - that SHOULD have stayed experimental, it sure wasn't cooked
when we reimported it into 2.0. [Newcomers, do be aware that
we punted proxy OUT of httpd 2, it was so horrid. It was
significantly refactored, and reintroduced, but brought back
as many new bugs as the refactoring eliminated.]
* ssl - I'm under the impression (and could be wrong) that most of
the ssl issues are unusual, more experimental configurations
using features that even the mod_ssl project doesn't build
by default ;-)
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).
mod_charset_lite certainly isn't really an experiment - it's simply very
lightweight, and can't be built without iconv (or apr_iconv) support.
We should prune out things that are unmaintained - especially perchild -
but not things that are new.
[...]
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.
So it's no longer an experiment; move it to modules/filters/
* 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.
So they are new. Why does that make them experimental? If they work,
and will continue to be maintained, then move them to the right place.
* 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.
Question; does this require the apr-util features in 1.3?
* perchild keeps on going nowhere and should be removed until and
unless something happens.
++1 it should be removed from 2.2.x branch, period. THEN if something
good happens on trunk, we reconsider the new code.
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.
Almost entirely by the developer/power user group who paid close
attention to the flaws in the almost-unusable 2.0 implementation,
right? All three should work orders of magnitude better than in 2.1.
Of course auth, and proxy refactoring may still have (big) flaws. No
problem, that's what the alpha/beta/GA cycle is ment to catch & address.
We agreed post-2.0.36 that there should simply not be an /experimental/
tree in release versions. We didn't suggest that a module shouldn't be
promoted, and actually argued that /experimental/ be gone from trunk.
Classify the module correctly, commit working code, and at branch time
we decide what will be 'pruned' - such as what you suggest for perchild.
If you want to commit non-working, experimental code, then we can always
roll another sandbox to 'play' in until there is something worthy of
inclusion in trunk.
Bill
