[Python-Dev] check-in policy, trunk vs maintenance branch

Alex Martelli aleaxit at yahoo.com
Mon Nov 3 11:38:23 EST 2003

On Monday 03 November 2003 04:01 pm, Anthony Baxter wrote:
> >>> Michael Hudson wrote
> >
> > Well, it's more practice than policy.  I guess the (my...) thinking
> > was that the trunk gets more testing, so it's a proving ground for
> > fixes.
> >
> > It also depends on who's going to be release monkey for the next point
> > release.  The branch is to a certain extent "theirs" and they should
> > get to decide how things work.  I'm not sure who's got the hat at the
> > moment (Anthony?).
> Unless someone desperately wants it, I'm happy to keep on doing it. What

And a *big THANKS!* for this -- from us all, I'm sure.

> I'd prefer:
>   - Apply to trunk first (assuming, of course, that the patch isn't
> something that's only needed on the branch - at this point in time, I can't
> see that happening, as release23-maint and the trunk haven't diverged far
> enough yet)

No, but there may be some cases.  E.g., one of the doc fix I proposed (but 
didn't commit) is to the reference manual, documenting that list 
comprehensions currently (2.3) "leak" control variables, but code should not
rely on that since it will be fixed in the future.  That doc fix would not 
make much sense in 2.4, assuming the leakage will be fixed then, as
it is currently predicted it will be.

>   - Mark (in checkin message) if the patch is a bugfix candidate
>   - If you're comfortable that the patch is a non-controversial bugfix,
> then commit it to the branch as well, AFTER you have run the unittests on
> the branch to make sure it still works)

[nod] yes -- makes a lot of sense.

> What makes for a controversial vs non-controversial patch? There's a couple
> of things I think are important to bear in mind:
>   - Functionality changes are controversial. Unless there's been a
> discussion and agreement (or BDFL fiat <wink>) on python-dev, it shouldn't

Surely the BDFL could afford a better car than _that_?!-)

> go in. - Major changes just near a release are going to be controversial,
> as it makes the life of the release-monkey-of-the-moment more painful.

Good point.

> At the end of the day, if you're not sure your patch should go to the
> branch, then mark it so in the checkin message, and someone (me, mwh,
> someone else willing to look into it) can make a judgment call.


> On the other hand, no-one's going to jump up and down screaming if you do
> check something in that probably shouldn't have gone in - we can always
> just revert it if necessary. I reserve the right to jump up and down if
> someone checks something in when I'm in the middle of a release and the
> branch is frozen, though <wink>.

Makes sense.

> Also, if you're checking something into the branch, please try and make it
> obvious that the change is a backport or whatever. Something like
> Backport of <trunk checkin message>
> is good.

Unfortunately I didn't do that for my check-ins this weekend ('cause they
weren't backports...:-) but sure, I will try and clarify that in the future.

As soon as I can make time, I'll "forward-port" to the 2.4 trunk the fixes
I had made only to the 2.3 maintenance branch.


More information about the Python-Dev mailing list