[Zope3-dev] set_trace in ZODB

[Jim Fulton]

Tim Peters wrote:
> [jürgen Kartnaller]
> 
>>>Just found a set_trace in ZODB/Connection.py
>>>
>>>Is this intended ?
> 
> 
> Good eye!  It apparently was by someone during the recent ZODB sprint,
> but it certainly wasn't intended to persist beyond the branch it was
> used in.  It's fixed now -- thanks for the report.
> 
> [Jim Fulton]
> 
>>No.  I also can't easily fix it in the Zope 3 tree
>>because we are now using svn:external.
> 
> 
> That's not "a fix", though -- would have left it broken in (at least)
> ZODB 3.4 branch, ZODB trunk, and in Zope2.

I would have fixed it in the trunk too.  I wouldn't have
thought of the 3.4 branch.

> 
>>I need to find out the process that Tim wants to follow.
> 
> 
> Same as changes to any other project you don't normally work on: 
> submit a bug/patch to the collector, and/or raise a stink about it on
> that project's mailing list.  IOW, if you don't know how to fix a
> thing, don't guess -- report it to someone who does.

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

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

>>I guess I need to:
>>
>>  - Fix it in the ZODB trunk
> 
> 
> That's step 2 now.  The first step was fixing ZODB 3.4 branch.  Then
> merge the fix to ZODB trunk (because ZODB 3.4a1 was released, the ZODB
> trunk is for 3.5 develpment now).  Then check that ZODB 3.3 branch and
> ZODB3 Zope-2_7-branch don't also have the problem. (And I already did
> all that stuff -- there's nothing left to do here.)
> 
> 
>>  - make a new tag
>>
>>  - change the Zope 3 svn:externals to point to the new tag.
> 
> 
> In this case, I didn't do either of those, because Zope3 is already
> using a unique-to-Zope3 tag (ZODB/tags/3.4.0a1-Zope3), to fix a
> unique-to-Zope3 problem with a ZODB test (obscure dependence in a
> hand-coded pickle on ZODB's Persistence, which latter Zope3 doesn't
> include).
> 
> So instead I merged this change to that tag. 

which breaks tag rules.  Now that tag is really a branch.

 > Instead I could have
> deleted the tag, then recreated it from 3.4 branch again; I had a weak
> reason to prefer the former in this specific case.
> 
> 
>>I think I'll wait to see what Tim thinks.  This is not urgent
>>because Zope 3 doesn't use this API.
>>
>>OTOH, Zope 2 *does* use this API and the problem is there too.
> 
> 
> Yes, the problem exists in ZODB/tags/3.4.0a1, and Zope 2.8a2 was
> already released using that tag.
> 
> "Between releases" I recommend pointing externals at the appropriate
> development branch, so that bugfixes to externals automatically show
> up in the clients that intend to use the next release on an external's
> development branch.
> 
> In the case of Zope2, that means I recommend redirecting its ZODB
> externals to ZODB/branches/3.4 for now (this is a dead-easy change --
> two "svn propedit"s; "svn up"; run the tests; commit if successful,
> revert if not).

Then that means that a change tou make to the 3.4 branch could break
Zope 2 unless you run the Zope 2 tests before the checkin.

Of course, if some project you don't know about follows the same strategy,
you won't know to run their tests.

> In the case of Zope3, I recommend leaving its ZODB externals pointing
> at ZODB/tags/3.4.0a1-Zope3 until an X3.1 branch is made from the Zope3
> trunk.

What is the reasoning behind this recommedation?

In any case, I wouldn't have been able to predict what you wanted to do.
So, I would have had to "follow the process" and submit a bug report.
If I had significant breakage, I'd be in a bad spot.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org