[Zope3-dev] set_trace in ZODB

[Chris McDonough]

Where *was* this set_trace?  I have a suspicion I'm missing some checkin
notifications; I don't see any messages that show it getting fixed in
zope-checkins or zope-cvs (neither in my incoming mail nor in the
archives).  I actually just wanted to make sure I didn't do it ;-)

On Sun, 2005-04-03 at 14:38, Tim Peters wrote:
> ...
> 
> [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.
> _______________________________________________
> Zope3-dev mailing list
> Zope3-dev at zope.org
> Unsub: http://mail.zope.org/mailman/options/zope3-dev/chrism%40plope.com
>