[Zope-dev] Re: tortoise v. hare

[Tres Seaver]

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.
> 
> 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?

I just looked at the latest version of Cache.py, and one reason I can 
see (besides the one Chris mentions) for slighting it is that it 
conflates "stylistic" changes with "substantive" ones.  I have a hard 
time evaluating the intent of the changes, because I can't isolate the 
substance.  For instance, a bunch of code is re-ordered in the file, 
sometimes with "trivial" formatting changes thrown in.  Jamie, is your 
version truly based on 1.10?  Or had you been maintaining your fixes and 
had the module change radically out from under you?

If I do a "surface cleanup" of Cache.py, would you be willing to 
generate a new patch against it for any substantive issues I miss?

Tres.
-- 
===============================================================
Tres Seaver                                tseaver at zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com