> >>> 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.
I don't care how de-stabilized the code base becomes. We have an MPM that absolutely does not work right now. I have committed a note explaining that I finally figured out how to solve the bug, and you tried to veto the whole concept of fixing the module. Even more, I am most likely to ONLY touch the MPM or fix bugs that exist in the core that stop the MPM from working. How can you even think of veto'ing that? > > 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. This isn't gratuitous. The MPM doesn't work, period. If it worked, it wouldn't be an issue. As for side-effects of rewrites, they happen. If the code is easier to maintain moving forward as a result of the rewrite and the code is better because of the rewrite, then the rewrite was worthwhile, and the side-effects are a small price to pay. > 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. This is really simple. If there is a bug, it needs to get fixed. If a developer says they want to fix something, then they should be allowed to. The whole idea of telling somebody that they can't do something is completely borked. My main complaint with this though, is that we shouldn't be throwing out vetos left and right. We should be having conversations and coming to resolutions without vetos. Vetos should be rare, and only used in extreme situations. Seeing at least one veto every week is part of what makes this less fun. Ryan
