httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Issues for 2.1.8
Date Tue, 20 Sep 2005 22:44:36 GMT
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


Mime
View raw message