[Zope-dev] tortoise v. hare (was: BTrees strangeness)

[Jamie Heilman]

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.