-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The releases are done. Thanks, both the 3.0 branch and the trunk are now open for commits.
- -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIrNyb2YZpQepbvXERAq/WAJwMG1nc/7K3D+fgXFOnoYbJ2bmJoQCeNa3Z ssE/3G13S9YLkXUHt3ivJhY= =I46l -----END PGP SIGNATURE-----
On Wed, Aug 20, 2008 at 8:10 PM, Barry Warsaw barry@python.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The releases are done. Thanks, both the 3.0 branch and the trunk are now open for commits.
Since the next step is release candidates, I have two questions:
- Do commits now require a code review?
- Should we make release blockers out of anything we think must be fixed before final?
-Brett
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Aug 20, 2008, at 11:24 PM, Brett Cannon wrote:
On Wed, Aug 20, 2008 at 8:10 PM, Barry Warsaw barry@python.org
wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The releases are done. Thanks, both the 3.0 branch and the trunk
are now open for commits.Since the next step is release candidates, I have two questions:
- Do commits now require a code review?
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.
- Should we make release blockers out of anything we think must be fixed before final?
Yes.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSK1fGHEjvBPtnXfVAQJHvQP/TUKrvwiIoJOLXjEMwtMTjl2+9sH9d4PH 4iQ7BBJTPUiSW+t31H+G535huJiC0JBOLRziS1r+cO2KNtF66CkpnRrlDK9M/nbz Uhe1CxYfMQLinMvIuPoGiT11qu5uNej8XackQX5v/OX1I96vKenaC/TFuELSvua/ gRGP6K/vS6o= =0rBw -----END PGP SIGNATURE-----
[Brett]
Since the next step is release candidates, I have two questions:
- 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]
- 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/)
On Thu, Aug 21, 2008 at 9:29 AM, Guido van Rossum guido@python.org wrote:
[Brett]
Since the next step is release candidates, I have two questions:
- 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?
That's what I was thinking; either real name or username, which ever you remember at the time. Since we don't have a way to flag an issue with a patch as needing a committer review, either we just continually check for release blockers with patches or we email here saying what issues have a patch ready and just need a second review.
-Brett
participants (4)
-
Barry Warsaw -
Bill Janssen -
Brett Cannon -
Guido van Rossum