[Python-Dev] RFC: trunk checkins between now and 2.5 final (original) (raw)
Anthony Baxter anthony at interlink.com.au
Wed Jun 28 19:42:55 CEST 2006
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] RFC: trunk checkins between now and 2.5 final
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This is a request for comments - this is my current thinking on a policy for checkins to the trunk between now and the release of 2.5 final.
Now that we're in beta:
If you don't add an entry to Misc/NEWS, a test (if relevant or possible) and docs (if relevant), the checkin is probably going to get reverted. This continues through the release candidate stages. I mean it about Misc/NEWS, too. Every change to the code gets a NEWS entry.
If it adds a feature in beta, and you didn't get signoff first, it's going to get treated as a revert candidate. People like myself or Neal shouldn't have to run after you to review the patch after it's in SVN.
If a checkin breaks the buildbots, unless the bug is very shallow and it's easier for someone of us to fix than revert, it's going to get a little set of three red dots on it's forehead ala Predator.
Once we hit release candidate 1, the trunk gets branched to release25-maint.
On release25-maint, between rc1 and 2.5 final:
If you checkin to that branch, get signoff first. This is regardless of whether it's bugfix or feature. The checkin is going to get the big revert cannon targetting it, otherwise.
If you need to go round one of these things, get signoff (in public!) first, or else if not in public, mention the signoff in the commit message. Preferably in public, though.
Once 2.5 final is out, the normal maintenance branch guidelines come into effect for release25-maint. That is, bugfixes only. This is all documented in PEP-0008.
A few notes on rationale for my being such a pain in the backside about this:
Now that we're in beta, we should be spending the time nailing down bugs. Every feature added has the potential to add bugs - in addition, other people are going to have to review that change to make sure it's sane. There's only so many mental cycles to go around, and they should be spent on fixing existing bugs, not creating new ones .
Once we're in RC, we're going to really, really want to ratchet up the quality meter.
Between Neal and myself we have a fair amount of timezone coverage, so you should be able to get hold of one of us easily enough. My contact details (including all manner of instant messenger type things) are also pretty easy to find, they've been posted here a number of times before.
Anyway, this is the current thinking. Am I being too dogmatic here? Comments solicited.
As far as people to sign off on things, Neal, myself or Guido should be the ones to do it. Course, Guido will probably decide he doesn't want this dubious honour .
Anthony
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] RFC: trunk checkins between now and 2.5 final
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]