[python-committers] Trunk and 3.0 branch are now open

[Guido van Rossum]

[Brett]
>> Since the next step is release candidates, I have two questions:
>>
>> 1. Do commits now require a code review?

[Barry]
> Ideally, all comments are reviewed <wink>, but I think the current
> arrangement will have to work for the rc's.  I'd say be even more careful
> about the changes you introduce in behavior or API.

I think it makes sense now to require review by another committer for
*all* changes until the final release, even trivial fixes of obvious
bugs, with the exception of doc fixes. This would also allow touching
up docstrings and comments without review. To enforce this, how about
the requirement of adding "Reviewed by <username>" to the checkin
comment?

[Brett]
>> 2. Should we make release blockers out of anything we think must be
>> fixed before final?

[Barry]
> Yes.

Right. This means that anything that's not a release blocker should be
considered okay to leave unfixed. There are enough release blockers
left that we'll have our hands full fixing just those.

We need to start triaging bugs with the goal of a rock solid release
-- many bugs found at this point (or long known) are better left
unfixed rather than destabilizing the release. There is no exact
science to this, no hard and fast set of rules -- but before deciding
to fix a bug, please consult at least one other committer, and when it
doubt, mail the list. It's much better to leave some bugs unfixed than
to stumble badly in the rush towards one more fix.

As for anything that smells like a feature, Just Say No!

And finally: merges from the trunk to 3.0 should be done *very*
carefully. I request that whoever does a merge runs the full test
suite (with --uall) before committing.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)