Ryan Bloom wrote:

>>>   RELEASE NON-SHOWSTOPPERS BUT WOULD BE REAL NICE TO WRAP THESE UP:
>>> +
>>> +    * With AP_MODE_EXHAUSTIVE in the core, it is finally clear to
>>>
>me
>
>>> +      how the Perchild MPM should be re-written.  It hasn't worked
>>> +      correctly since filters were added because it wasn't
>>>
>possible to
>
>>> +      get the content that had already been written and the socket
>>>
>at
>
>>> +      the same time.  This mode lets us do that, so the MPM can be
>>> +      fixed.
>>>
>>-1 on an MPM rewrite until after 2.0 GA is released
>>
>
>Huh!?!?!?!?  You can't veto fixing code that doesn't work.
>

If you were just proposing a fix, I'd have no objections (well,
until I saw the code :-)  The crucial difference is that you're
talking about a rewrite of a large amount of code.  We've seen
how badly the code base becomes destabilized after major rewrites.

>  Even more,
>you can't veto work that somebody wants to do.  The whole point of Open
>Source is that we all get to do what is most interesting to us.
>
>I am fairly confidant in saying that I want to see a GA release more
>than anybody else here, except for possibly Bill Stoddard, because the
>two of us have been working on 2.0 for longer than anybody else on this
>list.  However, this push for GA regardless of quality or how fun the
>project is really makes me wish that we weren't nearly so close to one.
>

With regard to quality, that's exactly why we need to stop
doing gratuitious rewrites of large subsystems.  While it's
not impossible to make such changes work, the code quality
has dropped with each major change--and it's taken a lot of
work to fix all the peripheral things that got broken as
side-effects of rewrites.

As for "how fun the project is," I'm in agreement that that's
something we all consider when deciding what code to write, but
it's usually not a criterion that I apply when evaluating commits.
The reason is that a big code rewrite can yield O(1) incremental
fun but O(n) incremental work: it's fun for the person who writes
the code, but a lot of extra work for n other people who end up
debugging it once it's in the code base.

--Brian


Reply via email to