Re: [Zope-dev] tortoise v. hare (was: BTrees strangeness)
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] tortoise v. hare (was: BTrees strangeness)
On Wed, 2004-05-19 at 16:29, Jamie Heilman wrote: > Chris McDonough wrote: > > 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. Can't help you much there. FWIW, I don't work for ZC anymore and I'm still not willing to sponsor the wholesale introduction of that code either, so I don't think it's necessarily a ZC problem. You could say that the community of people with CVS contributor access is cutting off their nose despite their faces, I guess that would make sense (with the usual caveats of time vs. benefit). > > 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. Actually it would be helpful if patches that fix bugs came in as small and easily-understood diffs. That would make the intent clearer and would make it more likely to be sponsorable (at least by me, anyway). Having high-quality, small, clear bugfix diffs waiting to apply on regular bugdays would help move us forward a lot, especially on maintenance branches. - C ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] tortoise v. hare (was: BTrees strangeness)
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. 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 eternity, or longer ;-) 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. 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. - C On Wed, 2004-05-19 at 14:43, Jamie Heilman wrote: > Tres Seaver wrote: > > > > We should have a 'hasattr-geddon' and remove every trace of that > > monstrosity from Zope and the CMF; likewise a 'bareexcept-geddon' > > (there might be a few places which are smart enough to do 'except:', but > > I doubt it). > > Now its not a geddon by any means, but the code I wrote and offered in > bug 911 fixes 3 (iirc) bare excepts, a couple of privacy holes, > several bugs, and adds some enhancements that my tests have shown are > basically backwards compatible with everything out there (though I > didn't realize at the time CMF had a cache manager of its own and I'm > not sure how they interact). Its been a year now since I offered that > code and I haven't gotten so much as a comment on it. Maybe its time > to wander over and give it a look? ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] tortoise v. hare (was: BTrees strangeness)
Tres Seaver wrote: > > We should have a 'hasattr-geddon' and remove every trace of that > monstrosity from Zope and the CMF; likewise a 'bareexcept-geddon' > (there might be a few places which are smart enough to do 'except:', but > I doubt it). Now its not a geddon by any means, but the code I wrote and offered in bug 911 fixes 3 (iirc) bare excepts, a couple of privacy holes, several bugs, and adds some enhancements that my tests have shown are basically backwards compatible with everything out there (though I didn't realize at the time CMF had a cache manager of its own and I'm not sure how they interact). Its been a year now since I offered that code and I haven't gotten so much as a comment on it. Maybe its time to wander over and give it a look? -- Jamie Heilman http://audible.transient.net/~jamie/ "You came all this way, without saying squat, and now you're trying to tell me a '56 Chevy can beat a '47 Buick in a dead quarter mile? I liked you better when you weren't saying squat kid." -Buddy ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )