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

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

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 Fulton           mailto:[EMAIL PROTECTED]       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org
Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to