On Fri, Jun 13, 2008 at 7:27 AM, Georg Brandl g.brandl@gmx.net wrote:

Guido van Rossum schrieb:

...

On Fri, Jun 13, 2008 at 6:54 AM, Facundo Batista facundobatista@gmail.com wrote:

...

2008/6/13 Barry Warsaw barry@python.org:

...

My proposal is this: I will spin another release this coming Wednesday, June 18. If we can get both the 2.6 and 3.0 buildbots green by then, and close out all remaining release critical bugs, then Wednesday's release will be beta 1. In that case, I will update PEP 361 and push the entire schedule back by 2 weeks to account for our slippage.

Next weekend, 21 and 22, it will be the Python Bug days.

Maybe it's worth to delay the betas one week to include this work?

You mean one more week? (Barry's already delaying them one week.)

I'm fine with whatever delay Barry approves, but I want EVERYONE to stick to the purpose of the delay: get the buildbots green and close out release critical bugs. This means no new last-minute features or big refactorings (unless there's really no more conservative way to fix a critical bug). It also means try to get at least one other person to review every change, no matter how small (or big!) *before* submitting. It also means run the tests before submitting.

That is a new policy, isn't it?

Yes -- one that seems appropriate during a beta release period (i.e. until 2.6 and 3.0 final are out).

...

On the specific purpose of delaying for the bug day, I'm hesitant -- bug days tend to cause a great deal of commits of code by relatively new developers, which is counter to our purpose of stability. I would almost say it's better for the bug day to fall right after the beta. That also has the advantage that the bug day can focus on new bugs in the beta, and squash them right away...

+1.