<br><br><div class="gmail_quote">On Wed, Mar 26, 2008 at 1:21 AM, Neal Norwitz <<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The next releases of 2.6/3.0 are planned for April 2, just over a week<br>
from now. There is much work that needs to be done. The buildbots<br>
are in a pretty sad state and the gods are seeing too much red.<br>
<br>
<a href="http://www.python.org/dev/buildbot/stable/" target="_blank">http://www.python.org/dev/buildbot/stable/</a><br>
<a href="http://www.python.org/dev/buildbot/all/" target="_blank">http://www.python.org/dev/buildbot/all/</a><br>
<br>
See my other mail that discusses the stable buildbots. The criteria<br>
for release is that all the stable buildbots are passing all the<br>
tests. So we really gotta get these green before Barry notices. You<br>
don't want to see Barry angry. You wouldn't like him when he's angry.<br>
<br>
I propose a code chill for new features. Changes to doc and tests can<br>
continue as usual. However, only submit a new feature *after* you fix<br>
a broken test first. If we have to get draconian, we can start<br>
breaking fingers when you break a test just like we do at work. :-)<br>
<br>
Specifically tests that need some TLC are:<br>
* test_winsound<br>
- <a href="http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0" target="_blank">http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0</a><br>
* test_threading - test_no_refcycle_through_target<br>
- <a href="http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0" target="_blank">http://www.python.org/dev/buildbot/stable/x86%20XP-3%20trunk/builds/1166/step-test/0</a><br>
* test_socket deadlocks and times out<br>
- <a href="http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0" target="_blank">http://www.python.org/dev/buildbot/stable/x86%20W2k8%20trunk/builds/210/step-test/0</a><br>
* test_ssl deadlocks and times out<br>
- <a href="http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0" target="_blank">http://www.python.org/dev/buildbot/all/S-390%20Debian%20trunk/builds/255/step-test/0</a><br>
* test_xmlrpc transient socket errors<br>
- <a href="http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0" target="_blank">http://www.python.org/dev/buildbot/stable/g4%20osx.4%20trunk/builds/3101/step-test/0</a><br>
* test_mailbox<br>
- <a href="http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0" target="_blank">http://www.python.org/dev/buildbot/stable/x86%20XP-3%203.0/builds/723/step-test/0</a><br>
* test_asynchat<br>
- <a href="http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0" target="_blank">http://www.python.org/dev/buildbot/all/alpha%20Tru64%205.1%20trunk/builds/2756/step-test/0</a><br>
<br>
Hopefully test_timeout is fixed, but that might be flaky too. There<br>
have been other tests that have also been flaky like test_asynchat,<br>
test_smtplib, test_ssl, test_urllib2net, test_urllibnet,<br>
test_xmlrpc_net and some of the tests that use networking. These all<br>
need to be fixed so the tests are 100% reliable and only fail when<br>
there is a real error.<br>
<br>
There are currently no release blocker issues:<br>
<a href="http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=1&%40group=priority&status=1&%40action=search" target="_blank">http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=1&%40group=priority&status=1&%40action=search</a><br>
<br>
There are 48 critical issues:<br>
<br>
<a href="http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=2&%40group=priority&status=1&%40action=search" target="_blank">http://bugs.python.org/issue?%40columns=title&%40columns=id&%40sort=activity&priority=2&%40group=priority&status=1&%40action=search</a><br>
<br>
If you believe any issue should block the release, set the priority to<br>
release blocker and assign it to me (nnorwitz). Many of the critical<br>
issues are those that require 2to3 fixers. These can be checked in as<br>
they are written. Be sure to test them thoroughly and try to think of<br>
all the conditions that could possibly cause the fixer to fail or do<br>
the wrong thing.</blockquote><div>There are also some backporting issues in that pile. Should those hold up betas? (when we get there)<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Right now, I don't know of any reason to hold up the release other<br>
than the failing tests.<br>
<br>
n<br>
_______________________________________________<br>
Python-3000 mailing list<br>
<a href="mailto:Python-3000@python.org">Python-3000@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-3000" target="_blank">http://mail.python.org/mailman/listinfo/python-3000</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com" target="_blank">http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Cheers,<br>Benjamin Peterson