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

[Anthony Baxter]

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

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

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

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.

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>   
It's never too late to have a happy childhood.