Re: [Python-Dev] Status of the Buildbot fleet and related bugs
On Fri, Nov 6, 2009 at 3:53 AM, R. David Murray wrote: > (1) issue 3864: FreeBSD testing hangs consistently. According to the > ticket this is a FreeBSD bug fixed in 6.4, so an OS upgrade > on the buildslave would probably solve it. I think the particular issue mentioned in 3864 is fixed, in some sense: test_signal used to hang, but now just plain fails in a reasonable amount of time (~15 seconds) instead. So at least the test_signal failure isn't preventing us from seeing the results of other tests. The big problem now on the FreeBSD buildbot is that test_multiprocessing reliably causes the whole test run to abort with 'Signal 12'. Solving this may be as simple as just getting someone to install a copy of FreeBSD 6.2 on an ssh-accessible machine so that the source of the error can be tracked down. > (2) issue 4970: consistent signal 32 error on the norwitz-x86 Gentoo > buildslave in 3.1 and 3.x. This may be due to the box > running an old threading library, but it does make one wonder what > changed in 3.x that exposed it. This error has been happening since well before 3.0 was released. Asking for access to Neal's machine is probably the only sensible way to diagnose it. (A less invasive but slower way to debug would be to create a branch especially for this bug and do repeated runs to figure out which part of test_os is causing the failure.) > Another issue that I've seen on the buildbots but that doesn't > seem to be showing up right now (is it fixed?) is issue 7251, which > Mark is working on. It's not fixed, but I hope to have time to fix it this weekend. It's just not showing up on some runs because test_multiprocessing kills the buildslave first. :-) > So, overall I think the buildbot fleet is in good shape, and if > we can nail issue 6748 I think it will be back to being an > important resource for sanity checking our checkins. Wholeheartedly agreed! Sorting out the FreeBSD test_multiprocessing Signal 12 would be nice, too. I'll open an issue for this, unless someone else gets there first. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of the Buildbot fleet and related bugs
R. David Murray schrieb: > The buildbot waterfall is much greener now. Thanks to all who have > contributed to making it so (and it hasn't just been Mark and Antoine > and I, though we've been the most directly active (and yes, Mark, you > did contribute several fixes!)). [...] > In the 'unstable' builder fleet, Antoine's new builder seems to be > stable across the board, while mine fails consistently on 3.1 and 3.x > because of the test_telnetlib bug. Thomas Heller's OS X buildbot is > consistently having lots of test failures (the same ones each time > I've checked). My buildbot is behind our companys firewall. Well, I was able to fix the test_smtpnet test by additionally opening port 465 in the firewall; however I'm not really sure I should do that. I had to open another port already although that one is probably less critical. For the other test failures, I have no idea where they come from. -- Thanks, Thomas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
Brett Cannon wrote: > On Thu, Nov 5, 2009 at 19:23, Guido van Rossum wrote: >> On Thu, Nov 5, 2009 at 3:35 PM, Brett Cannon wrote: >>> On Thu, Nov 5, 2009 at 15:26, Guido van Rossum wrote: I have come to the conclusion that there are better ways to pre-announce that a module is going to disappear instead of deprecation warnings. >>> What exactly are those better ways? Document as deprecated only? >> Sorry, I have an existence proof, but no construction. :-) >> >> Ideas welcome. Silent deprecations, loud documentation, biweekly home >> visits, whatever, as long as it doesn't log a message by default. > > Well, one option is to come up with the equivalent of -3, but for all > warnings; the antithesis of -W. And obviously glaring deprecation > warnings in the docs (removal has been discussed but always shot down > as someone who comes across old code might still need docs for it). For a PEP 3003-specific solution, we could adopt a policy that we will add only Pending Deprecation warnings during the moratorium period. The actually deprecation clock would then only start in the first release after the moratorium ends (i.e. full Deprecation Warning in that release, removal in the following release). No doubt some third party developers would end up being shocked by a raft of warnings at that point, but those that are paying more attention would get a chance to clean up the warnings without alarming their users. Longer term, a solution may be to extend the standard deprecation period one release and make pending deprecation warnings required rather than optional. That way, on the ball developers would have a full release to quash deprecation warnings before their users encountered them by default. That is: Release X.Y: deprecated in docs, pending deprecation in code Release X.Y+1: deprecated in code Release X.Y+2: removed in code and docs (Or we could just make that the policy now and not do anything specific in relation to the moratorium and the standard library) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On Fri, Nov 6, 2009 at 6:18 AM, Steven D'Aprano wrote: > I don't know how mature or active it is, so it may not count as either > major or complete, but there's also CLPython: > > http://common-lisp.net/project/clpython/ CLPython is in steady development, quite complete and stable on the language level (somewhere between 2.5 and 2.6), but missing most built-in library functionality. (It reuses the pure-Python parts of the stdlib.) As its developer, I don't care much about being mentioned in discussions or presentations, as CLPython is not as widely used as IronPython and Jython. But in a PEP like this, which is directly about alternative implementations, it deserves to be mentioned, IMHO. - Willem ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On Fri, Nov 6, 2009 at 10:35, Nick Coghlan wrote: > Longer term, a solution may be to extend the standard deprecation period > one release and make pending deprecation warnings required rather than > optional. That way, on the ball developers would have a full release to > quash deprecation warnings before their users encountered them by default. > > That is: > > Release X.Y: deprecated in docs, pending deprecation in code > Release X.Y+1: deprecated in code > Release X.Y+2: removed in code and docs > > (Or we could just make that the policy now and not do anything specific > in relation to the moratorium and the standard library) This sounds like an improvement for things like Mercurial, at least. We did support 2.3-2.6 until relatively recently, and I think that's hard to get around for software that actually has to work on the user's box. This is a bit different from webapps, I suspect, where you "only" have to support the servers, which you often have more control over. But supporting 4 releases in a row has been a bit of a PITA. Luckily, we finally felt it was time to drop 2.3, so now we can make use of luxuries such as subprocess... Still, supporting 3 releases seems relatively common in the Python world (after all, parts of Zope still require 2.4, I think), and so it would be nice if the stdlib moved a little bit slower. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
