[Zope3-dev] set_trace in ZODB

[Tim Peters]

...

[Jim]
>>> Oh come on. Do you really want to be the only one who checks in
>>> ZODB fixes?

[Tim]
>> No, but l'm sick of endlessly searching for, and merging, ZODB fixes I
>> didn't even know about, checked in from wrong projects.  I would love
>> for more people to check in ZODB fixes _to_ ZODB.  Then the problems
>> are truly fixed, instead of kicking off waves of extra work that I in
>> fact am the only one who has ever done.

[Jim]
> Fair enough.  It shouldn't have been your responsibility to take
> case of Z2 or Z3 uses of ZODB. For example, I should have fed back
> ZODB changes in an orderly way and been responsible for updating Z3
> to use newer ZODBs.

It's more that it was nobody's responsibility, really -- I've been
filling what appeared to be major vacuums.  More checkins to ZODB code
got made from Zope trunk anyway -- the last time I had to set aside "a
merge day", there were actually no "rogue" checkins from Zope3 trunk,
they were all from Zope trunk.  I expected that too, since all
developers from Zope2-land, and whether consciously or not, have the
CVS symlink magic in their mental model of how things work (where it
doesn't matter from which project checkins are made, they show up in
all clients at once and by magic).

zdaemon and ZConfig are in similar boats.  I _used_ to try to keep
zdaemon in synch across its SVN clients, but haven't done so for quite
a while.

...

>>> If some project has serious breakage it will often be unacceptable
>>> to wait for a fix.

>> I have a hard time buying "often" there, since I can't recall an
>> example of this in recent memory.

> Possible the reason is that we have been insulated from this problem
> by using copies.

That can't account for why we haven't had any such problems in
CVS-land either in recent memory, where copies aren't made.  I'm
extraordinarly careful about checking in ZODB changes there, and there
isn't any new-feature development in ZODB 3.2, and I bet both of those
have a lot to do with the lack of recent sharing problems in the Zope
2.7 line.

...

> I'm willing to continue with the current experiment for now.
> I think it's telling that we already have an issue, admittedly a
> small one, with the new scheme.

And I exacerbated this by trying to take shorcuts (I have about 7
hours of personal tasks I have to finish today too -- I'm not in the
mood <0.5 wink>).

So I'm doing a right thing here now:  I made an "internal" ZODB 3.4a2
release, incorporating the little changes made since Friday's 3.4a1
release.  Assuming tests pass (they will ...), I'll switch Zope and
Zope3 trunks to use the ZODB/tags/3.4.0a2 tag.  That's "a real tag"
even to you <wink>.  I'll delete my goofy Zope3-specific 3.4a1 tag
then.

What happens after that is open to debate (e.g., I keep doing this, or
someone else does) -- I'll at least be leaving it in a wholly sane
state today.

> It was a mistake to saddle you with maintaining Zope3's usage of ZODB.

That's not really my claim here, although it may be true.  The mistake
is that it hasn't been clear exactly who _is_ responsible for Zope3's,
or Zope 2.8's, usage of ZODB -- or of ZConfig or zdaemon.