Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Tuesday, July 20, 2004 10:19 PM +0200 André Malo <nd...@perlig.de> wrote:

> the old outdated NCSA config directives? We add and add and add code -- which
> is not actually bad. But where's the man with the broom?

Sounds a like job for someone.  How about nominating modules for removal in 
2.1, or at the very least split them off to an 'unmaintained' distribution? 
We can leave them there, but boot them out of our 'core' distribution.  2.0 
saw the introduction of mod_dav and mod_ssl - two fairly large modules, but no 
real reductions elsewhere.

My #1 vote is to throw mod_rewrite clear off the island.  =)  -- justin

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Sunday, August 1, 2004 8:12 PM +0200 Mads Toftum <ma...@toftum.dk> wrote:

> On Sun, Aug 01, 2004 at 03:18:47AM -0700, Justin Erenkrantz wrote:
>> My #1 vote is to throw mod_rewrite clear off the island.  =)  -- justin
>
> Why is it so important to kill off mod_rewrite that this comes up from time
> to time? Just take a look at the cvs history if you think mod_rewrite is

To be clear, my comment above was only tongue-in-cheek.  I know people 
actually use mod_rewrite and didn't mean it seriously.  nd's done a great job 
of channeling the spirit of RSE to get mod_rewrite usable again.

However, there may be definitely real modules that we should consider retiring 
to an 'extra' distribution.

> If you really wan't to take the hatchet to httpd's source tree, then maybe
> you should start with dead/unused mpms and perhaps mod_cache which has never
> really made it to completion.

Ideally, we should target those modules that have equivalent functionality 
offered elsewhere.  One pre-req for separating out MPMs is that we need to 
make them DSO-able...  *shrug*  -- justin

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Mads Toftum <ma...@toftum.dk>]

On Sun, Aug 01, 2004 at 08:25:42PM +0200, Graham Leggett wrote:
> "Don't kill module A, kill module B instead". I suggest we don't kill 
> anything which has evidence of being useful.
> 
Agreed - I just felt a bit provoked by mod_rewrite always being the target
(and hadn't seen justins patch to mod_cache yet).

> And if something is "broken", "wrong", "bad code", "incomplete", then 
> submit some patches to fix the problem! This is why we have peer review, 
> so that different eyeballs get a perspective on possible flaws in the code.
> 
Take perchild for instance - noone has worked on that since rbb left, but
we still get people complaining because they expect it to work (regardless
of the big flashing warning sign)

> Deprecating code without supplying a suitable replacements in our new 
> code leaves users with just one choice which they will freely follow: 
> Use the old code.
> 
Check back in the archives for the discussion of why to get rid of mod_imap
and mod_asis (or at least leaving them off by default). Though in principle
I agree that crippling the server in a delayed "spring cleaning" frenzy
isn't a great idea at all - I just tried to come up with a couple of alternatives
if there really has to be trimming. I'd just rather not lose mod_rewrite in the
same way as the debugging log level of mod_ssl disappeared,

vh

Mads Toftum
-- 
`Darn it, who spiked my coffee with water?!' - lwall

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Sunday, August 1, 2004 8:25 PM +0200 Graham Leggett <mi...@sharp.fm> 
wrote:

> And if something is "broken", "wrong", "bad code", "incomplete", then submit
> some patches to fix the problem! This is why we have peer review, so that
> different eyeballs get a perspective on possible flaws in the code.

No, the problem is that if no one has maintained a module in years, we are 
doing our users a big disservice by shipping broken and unmaintained code. 
One way to indicate that is not ship them by default any longer.  They'd still 
be available if you relied upon them.  -- justin

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Graham Leggett <mi...@sharp.fm>]

Mads Toftum wrote:

> Why is it so important to kill off mod_rewrite that this comes up from time
> to time? Just take a look at the cvs history if you think mod_rewrite is
> unmaintained - Andre has been doing a great job on it and there's a fairly
> large userbase too.
> If you really wan't to take the hatchet to httpd's source tree, then maybe
> you should start with dead/unused mpms and perhaps mod_cache which has never
> really made it to completion.

"Don't kill module A, kill module B instead". I suggest we don't kill 
anything which has evidence of being useful.

And if something is "broken", "wrong", "bad code", "incomplete", then 
submit some patches to fix the problem! This is why we have peer review, 
so that different eyeballs get a perspective on possible flaws in the code.

Deprecating code without supplying a suitable replacements in our new 
code leaves users with just one choice which they will freely follow: 
Use the old code.

Regards,
Graham
--

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Mads Toftum <ma...@toftum.dk>]

On Sun, Aug 01, 2004 at 03:18:47AM -0700, Justin Erenkrantz wrote:
> My #1 vote is to throw mod_rewrite clear off the island.  =)  -- justin

Why is it so important to kill off mod_rewrite that this comes up from time
to time? Just take a look at the cvs history if you think mod_rewrite is
unmaintained - Andre has been doing a great job on it and there's a fairly
large userbase too.
If you really wan't to take the hatchet to httpd's source tree, then maybe
you should start with dead/unused mpms and perhaps mod_cache which has never
really made it to completion.
As I recall it, there was a great uproar when we suggested getting rid of
mod_asis and mod_imap, which are both essentially unused - so it doesn't
seem to make sense to go thrashing about in code that sees a fair bit of
use.

vh

Mads Toftum
-- 
`Darn it, who spiked my coffee with water?!' - lwall

Re: Taking a broom to our modules was Re: Invitation to HTTPD commiters in tomcat-dev

[Graham Leggett <mi...@sharp.fm>]

Justin Erenkrantz wrote:

> Sounds a like job for someone.  How about nominating modules for removal 
> in 2.1, or at the very least split them off to an 'unmaintained' 
> distribution? We can leave them there, but boot them out of our 'core' 
> distribution.  2.0 saw the introduction of mod_dav and mod_ssl - two 
> fairly large modules, but no real reductions elsewhere.

Reduction for reduction's sake doesn't achieve anything on it's own.

> My #1 vote is to throw mod_rewrite clear off the island.

Whether something gets booted off the island should be based on lack of 
users, not an apparent lack of maintenance.

A lack of maintenance could be caused by a number of things: the code 
works, and if it's not broken it doesn't need to be fixed (aka 
maintained); or the errors that do exist in the code are not major 
enough to inspire anybody to step forward and fix them.

If a module is to be deprecated, then a sensible alternative needs to be 
provided. Just chopping out modules for the sake of chopping just leaves 
annoyed users, and this: people saying "we're sticking with Apache v1.3, 
because v2.0 can't do XXX".

Regards,
Graham
--

Re: Taking a broom to our modules

[André Malo <nd...@perlig.de>]

* Justin Erenkrantz <ju...@erenkrantz.com> wrote:

> --On Tuesday, July 20, 2004 10:19 PM +0200 André Malo <nd...@perlig.de> wrote:
> 
> > the old outdated NCSA config directives? We add and add and add code --
> > which is not actually bad. But where's the man with the broom?
> 
> Sounds a like job for someone.  How about nominating modules for removal in 
> 2.1, or at the very least split them off to an 'unmaintained' distribution? 
> We can leave them there, but boot them out of our 'core' distribution.  2.0 
> saw the introduction of mod_dav and mod_ssl - two fairly large modules, but
> no real reductions elsewhere.

I think, this a good idea in general. In conclusion with some *very* easy
mechanism to add modules on the fly (something for a modules.apache.org
revision?). Perhaps a standard module distribution framework like in perl or
python, autogenerated makefile templates etc.

Anyway I'd start the list with mod_imap and mod_cern_meta...

> My #1 vote is to throw mod_rewrite clear off the island.  =)  -- justin

;-) mod_rewrite is now maintained again (since my huge commitments some months
ago). Hey, it's even faster now ;-))

nd
-- 
Winnetous Erbe: <http://pub.perlig.de/books.html#apache2>