[Python-Dev] A "new" kind of leak

[Tim Peters]

[Michael Hudson]
> For patches that
>
> cvs up -j blah -j blat file
>
> can handle, I have a setup that make porting them the work of seconds.
> It takes a little while to set up, so I batch them.

Maybe waiting for a change to show up in the trunk is a better way to go.
Since I was making the trunk change "live", and wasn't going to check
anything in before everything worked on both trunk and branch, -j was
impotent (in the way I happened to do this).  Regardless, it won't work for
*this* patch if it's desired in 2.1 (too much has changed).

> I don't run the tests for every checkin this way so I guess I risk
> pain -- if I plough through 20 or so fixes in a run and find
> somethings broken, working out what did it could be entertaining.
> Hasn't happened yet, though.

In this particular case, we don't have any machinery in the test suite for
detecting unbounded process growth, and I don't know a low-effort way to add
some that would actually work x-platform.  I did have a "by hand" test to
run, which runs forever while I stare at the output of a Windows
process-size sniffer.  So this particular case required running tests
manually, and if "it breaks" (in the sense of not clamping process growth)
someday, that won't be detected automatically.

> What I'm saying is, if getting fixes into the tree is awkward for you,
> don't worry about it /too/ much.

It would have been easier if I checked in the trunk changes first before
bothering with the 2.2 branch.  Still, the primary point stands:  when
writing the code goes fast (as it does with most bugfixes), and if
everything is great, it still takes more than N times as long to stick a fix
into N releases.  So batching 'em up may be an expedient idea, as it
certainly allows amortized some of the expenses (it all adds up!  and, e.g.,
doing a cvs up over the network in a branch burns the same amount of time
whether you're doing the update in preparation for backporting 1 fix or
1000).

> I want to fiddle my scripts a bit, but they should appear in Tools/ at
> some point...

Cool!