[Zope3-dev] set_trace in ZODB

[Tim Peters]

...

[Jim]
>>> I need to find out the process that Tim wants to follow.

[Tim]
>> 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.

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

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.

> 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.

If it does become that critical for project X using a broken external
Y, and Y's developers are unresponsive, fine, X can create their own Y
branch and make any changes they like there.

Even that assumes X can't fix their problems by backing off to an earlier X tag.

...

>> So instead I merged this change to that tag.

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

If I hadn't said that's what I did, you'd never know the difference. 
To me this is an academic debating point == no significance.  If it
bothers you enough that you want me to spend more time on it, fine,
I'll do this instead:

>> Instead I could have deleted the tag, then recreated it from 3.4
branch again;

The weak reason I had for not doing that is this:  if you do svn log
on the tag as-is, you get a complete record of checkin comments that
carefully explain why that tag exists.  If I recreated the tag
instead, the historical comments would get buried, unless I spent
extra time to combine and re-type them into the new tag-creation
checkin comment.

...

>> 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.

Yes.

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

That's one of the tradeoffs someone running a project is supposed to
make according to their judgment.  My recommendation for Zope2 follows
specifically from that Zope-2_7-branch has been using "current
development ZODB 3.2" for at least a year, and no problems have been
caused by that.  Since nobody else in Zope2-land takes any
responsibility for the version of ZODB Zope2 uses, I apply my best
judgment there -- my choice, my work, my problems.

If you want something different in Zope3-land, fine by me, but I just
hope it's backed by a plan for someone other than me to do the work
involved.

>> 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?

So that X3.1 uses ZODB/tags/3.4.0a1-Zope3 without the person who makes
the X3.1 branch needing to be aware of anything about how ZODB is
stitched in (making the branch will automatically copy the
svn:externals used by the trunk at the time the branch is made).  That
tag is 3.4.0a1 with the minimal changes needed due to Zope3
peculiarities, as close to a "real ZODB release tag" as is possible
for Zope3 to use (no, I'm not going to release 3.4a2 just to repair
the ZODB test that relies on Persistence in a hand-coded pickle, which
only matters to Zope3 -- the ZODB and Zope2 releases don't have a
problem with this, only Zope3 does).

Using svn:externals it's much more obvious how external projects get
stitched in, but still very easy to miss (you have to know to look at
the properties on lib/python/ and utilities/), and especially easy to
miss by people who have never stitched in anything (== everyone other
than you and me, possibly Fred).  I assume Stephan Richter will make
the X3.1 branch (because he said he would <wink>), and the
recommendation is to help him do a right thing here without having to
think about it (or even be aware of it).

> 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.

Or you would have done part of the work, and left it to me to try to
reconstruct what you did do and what still needed to be done.  In
effect, your original email to me was "submitting a bug report", and
the problem you reported got fixed minutes after I saw it -- you're
arguing about a process that worked great <wink>.

> If I had significant breakage, I'd be in a bad spot.

I'd rather save that discussion for a time when there is signficant
breakage.  This is all too hypothetical to me to worry so much about. 
In actual fact, only the Zopes stitch in ZODB, and I run their tests
every day.  If significant breakage occurs, it's easy to back off to
an earlier version -- and indeed _much_ easier to do so using
svn:externals than wrestling with umpteen svn copy'ed directories.