[Python-Dev] Porting bug fixes (was A "new" kind of leak)

[Tim Peters]

[Michael Hudson]
> ...
> So what I'm suggesting is that if you want a checkin to be ported to
> release22-maint you should add a specific bit of text to the chickin
> message.  Does this seem reasonable?

Yes, but you have to Pronounce on which specific bit of text you want to
see.  It's going to get much more complicated if we intend to backport fixes
across 2 or 3 years of older releases.  I predict that's not going to work
unless we establish an easy-to-update patch database recording which patches
have and haven't been applied to each old release, which should and
shouldn't be applied to each old release, and everyone is serious about
keeping that up to date.  I'm not aware of any commerical organizations with
full-time QA departments that sign up for something so messy, and I'm not
sanguine about our prospects of pulling it off (the older the code, the more
likely "a bugfix" is to create at least as many problems as it solves; and
the more active branches, the more likely fixes to get dropped on the
floor).

> Another random point: it would be nice if on checking a bugfix into
> HEAD people *said* if *they* planned to port the fix themselves.
> Otherwise I see the message that says "bugfix candidate", hit they key
> that copies it into my special bugfixes folder, then read on and find
> it's already been ported and have to go and find the copy and delete
> it.  TIA.

I already do all that stuff, so stop yelling at me <wink>.

[Martin v. Loewis]
> If I'm going to commit the same patch onto the maintainance branch, I
> usually don't mark it as "bugfix candidate".

Except that "the" maintenance branch loses clear meaning when there are
multiple maintenance branches.  That's why I expect this just isn't going to
work without a patch database:  it needs something independent of scattered
checkin messages to correlate a *conceptual* patch with all the active
branches.  Or it needs a truly dedicated person to sign up for each active
branch, who actively worries about every patch that comes by.  I expect Neil
spoke for most current developers there:  they don't fear current releases,
so won't volunteer for such work (there's no payback for them -- open source
works because developers and users volunteer to scratch their own *current*
itches, and share the relief; the "maintenance branch" business is unique in
that nobody with that particular itch has volunteered to do anything to
scratch it).