Chris McDonough wrote:
I've looked at that issue many times during various bug days and it sounded reasonable enough but it always seemed like slightly higher-hanging fruit than other issues because it introduces new features as well as fixes bugs.
Oh granted, it totally is. It just happens to be high hanging fruit I have a vested interest in, and don't mind squeeking about once a year. Now I've done my squeeking, so I'm good till '05.
Personally I prefer that someone who wants to introduce new features (even small ones, like API additions) into the core do it via their own committer privileges and thus sign up to maintain it for the rest of
Yeah well... we've been over that before, I refuse to sign that agreement. If that means my patches go ignored for eternity, so be it, but it really seems like ZC is just cutting of their nose to spite their face.
The reason I think people don't jump on collector issues like this one is because of the natural "he who touched it last owns it" policy of the core code. I own enough of Zope 2 core code to make me uncomfortable at this point; owning more just isn't very attractive to me unless the upside is very up.
Thats an unfortunate situation to be sure, I don't have any solutions to offer as its not a technical issue. All I can say is that we know the code doesn't care who touched it last, its going to break or work regardless. The sooner the community accepts that, the sooner we can get out of the rut and make some more progress.
Straightforward obvious bugfix patches with limited scopes are another matter; those usually get applied first during bug days. This is also why "geddons" are attractive; they focus effort on an isomorphic class of bugs without requring that the fixer wade through proposals for features, API improvements, and provides an effective loophole for "he who touched it last" problem.
Sure, I have nothing against geddons per se[1], but they just won't fix every class of problem. One of the advantages of OOP is being able to focus on a component of the larger system, replace it, and see how the system around it reacts. The clearly defined component boundries are a big advantage to that kind of development strategy, its a great way to make localized behavioral changes. I don't think any amount of geddon activity would solve the problems I've faced with the current result caching API. -- Jamie Heilman http://audible.transient.net/~jamie/ "I was in love once -- a Sinclair ZX-81. People said, "No, Holly, she's not for you." She was cheap, she was stupid and she wouldn't load -- well, not for me, anyway." -Holly [1] I'd love to see the DTML namespace qualification (see bug 1217) geddon occur, if for no other reason than to watch the resulting code-bloat totally school some of the "dtml uber alles" hold outs.