2008/9/4 Raymond Hettinger <python@rcn.com>:

Can I go ahead with some bug fixes and doc improvements or should I wait until after Friday?

Doc improvements: go ahead. Bug fixes: the patchs should be revised by other developer. (I'll be hanging around in #python-dev today and tomorrow, btw, ping me if I can help you) -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 4, 2008, at 12:14 AM, Raymond Hettinger wrote:

[Barry]

...

I'm not going to release rc1 tonight.

Can I go ahead with some bug fixes and doc improvements or should I wait until after Friday?

Doc fixes are fine. Please have bug fix patches reviewed by another python-dev member. Bonus points for any bug fix that closes a release blocker! :) - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSL/cL3EjvBPtnXfVAQKnmgQAlx89LWeq0hEmTRvTGy/DHIYioARqAisG wJAnZPqinbGI6pkyn0kiwgDOvNzstnFQSZsEFiAFU+iF+nbgkm8agcTf+eLXqCFK y+o0xXTi7fLXKuaGioY54kz3BcwQH17Ul3X6vRxBdCWYesAe3rIXprnNgt/Euuyy P5sZLKwfTls= =b3n4 -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 4, 2008, at 3:28 AM, Mark Hammond wrote:

Barry writes:

...

In addition, Mark reported in IRC that there are some regressions in the logging module.

3772 logging module fails with non-ascii data

Which according to the IRC discussion doesn't apply to py3k. The fix for 2.6 is quite trivial...

Thanks. Looks like Vinay committed this. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSL/cdHEjvBPtnXfVAQIb7gP9G2o8eSnWWfEmlanwoqiHGxgqUjQtx8Xz es/Sjclk5KZ2X4I/jITJcOxGDfTT3h7FX9tDQiUaIzZAVB66qyzWc3957bUwqeqS 9HNqfB4OoIa1Ds2+lukXpEPci6eddl2xVFEkejgsfdyS4q2/K1/R6URTPCXnPNiH zoiXNaEcBcM= =Zk4M -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 4, 2008, at 7:08 AM, skip@pobox.com wrote:

Barry> In addition, Mark reported in IRC that there are some regressions Barry> in the logging module.

Vinay apparently checked in some changes to the logging module with no review. In the absence of obvious bug fixes there that should probably be reverted.

Or did he commit Mark's patch from bug 3772? If so, that would count as a reviewed patch. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSL/cpnEjvBPtnXfVAQIkSwQApjBbIGgyV3X1oBhBLtRjTZrVDgFXPfRH XyXtVd1r75PT+24UuqPHWNC9l+/sKnUaYqH3kJbHG2duMyr/duG7j6EIJLzOz+QC SKwqtQr+WDBR0vpH3Q0wrUzQNXhtDyCjWx84IatRbKRVDUfbDlFQy/jj+SLvRBBR WGJTAFP1x5g= =mebg -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 4, 2008, at 9:45 AM, skip@pobox.com wrote:

Barry> Or did he commit Mark's patch from bug 3772? If so, that would Barry> count as a reviewed patch.

The checkin message says issue 3726:

Author: vinay.sajip Date: Wed Sep 3 11:20:05 2008 New Revision: 66180

Log: Issue #3726: Allowed spaces in separators in logging configuration files.

Modified: python/trunk/Lib/logging/config.py python/trunk/Lib/test/test_logging.py python/trunk/Misc/NEWS

I noticed because someone else (Brett?) questioned the apparent lack of review.

Yep, that's a different issue. Unless someone wants to vouch for the committed patch after the fact, could someone please revert the change and contact Vinay to get a proper fix reviewed? I noticed that he says in the tracker issue that what was committed was modified from the posted patch. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSL/zMnEjvBPtnXfVAQJY3QP+LNXhx1YGuCHSw/D2n0yVBj1PLLUbgYnp k/+zWWmvIRc8YSApV1YyYR4iXfqqYFoi1SH0eh7F1k9+2CZ51HHD0p6CZ0Eb1FQ2 405ocxT28R3UR/E0ozxFca3IuNhGPR2FI/BCfsLrdrA3UtHA4XvZMDvM3KxEMarl 9WdYgop/I8Y= =b6Ry -----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 7, 2008, at 10:51 AM, Fredrik Lundh wrote:

Barry Warsaw wrote:

...

I'm not going to release rc1 tonight. There are too many open release blockers that I don't want to defer, and I'd like the buildbots to churn through the bsddb removal on all platforms.

...

I'd like to try again on Friday and stick to rc2 on the 17th.

any news on this front?

(I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but have had absolutely no time to spend on that. is the window still open?)

There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. But it worries me because I think this is going to push the final release beyond our October 1st goal. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMP6/3EjvBPtnXfVAQIprQQAsWgxQPKyxM/rrG5TWL4UqI7xne6dLTjL Nx3OBpi8hcNXEqyxzoosFXXZy4PpSWU+SwxuI1YQT9rUjv/ks6yxu3cBcEVhtEHV KE34YS4D825tVGvbvpsOXF06fsfv5j5zZGB6hlSipZoiv1rhR3uEsO2zkWaI4eQ6 Ty2Cfuxu10A= =8eP5 -----END PGP SIGNATURE-----

Fredrik Lundh <fredrik <at> pythonware.com> writes:

So what's the new ETA? Should I set aside some time to work on the patches, say, tomorrow, or is it too late?

Given the state of things in the tracker, I'd say it doesn't look too late.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't think there's any way we're going to make our October 1st goal. We have 8 open release critical bugs, and 18 deferred blockers. We do not have a beta3 Windows installer and I don't have high hopes for rectifying all of these problems in the next day or two. I propose that we push the entire schedule back two weeks. This means that the planned rc2 on 17-September becomes our rc1. The planned final release for 01-October becomes our rc2, and we release the finals on 15-October. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMUnWXEjvBPtnXfVAQIEAQQAnut+CRyBAacC2zzptb5l9cphwke0sEjx THJXHCBUfidaEV7SCtyfkh6i+IpqynvFRsKyOYSWsMojAa5rO/iM6ZJLkUav9c62 IzweJ6Nw3UnOJ/7xksCesDVxDRncFtvu0eRUZWDkOsrNawL+Z21DGKtAuau/pgiY sFnKeyP7NX0= =ZNPm -----END PGP SIGNATURE-----

On Mon, Sep 8, 2008 at 12:13 PM, Guido van Rossum <guido@python.org> wrote:

On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <barry@python.org> wrote:

...

I don't think there's any way we're going to make our October 1st goal. We have 8 open release critical bugs, and 18 deferred blockers. We do not have a beta3 Windows installer and I don't have high hopes for rectifying all of these problems in the next day or two.

I propose that we push the entire schedule back two weeks. This means that the planned rc2 on 17-September becomes our rc1. The planned final release for 01-October becomes our rc2, and we release the finals on 15-October.

- -Barry

Perhaps it's time to separate the 2.6 and 3.0 release schedules? I don't care if the next version of OSX contains 3.0 or not -- but I do care about it having 2.6.

I'm not really sure what good that would do us unless we wanted to bring 3.0 back to the beta phase and continue to work on some larger issues with it. I also suspect doing two separate, but close together final releases would be more stressful than having them in lock and step. Just my pocket change, though. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."

Guido van Rossum wrote:

Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway).

I'm on Guido's side. Ok, from the marketing perspective it's a nice catch to release 2.6 and 3.0 on the same day. "Python 2.6.0 and 3.0.0 released" makes a great headline. But given the chance to get Python 2.6 into the next OSX version it's fine with me to release 3.0 a couple of weeks later. Python 3.0 is not ready for a release candidate. We just fixed a bunch of memory leaks and critical errors over the last week. And don't forget Windows! The Windows builds didn't get thorough testing because we didn't provide our tests with official builds. I'm +1 for a 2.6rc and another beta of 3.0 Christian

On Mon, Sep 8, 2008 at 5:22 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Christian Heimes <lists <at> cheimes.de> writes:

...

Ok, from the marketing perspective it's a nice catch to release 2.6 and 3.0 on the same day. "Python 2.6.0 and 3.0.0 released" makes a great headline.

It's not only the marketing. Having both releases in lock step means the development process is synchronized between trunk and py3k, that there is no loss of developer focus, and that merges/backports happen quite naturally.

I think that we've reached the point where very few things are merged from 2.6 to 3.0 -- I see a lot more "block" commits than "merge" commits lately. Also, the added activity in 3.0 doesn't involve merges at all, because it's all 3.0-specific. Sure, we lose the ability to add last-minute -3 warnings. But I think that's a pretty minor issue (and those warnings have a tendency to subtly break things occasionally, so we shouldn't do them last-minute anyway).

But I don't think it's an overwhelming argument either. I would value it at around 50 euro cents, not even the price of a good croissant ;-)

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

Antoine Pitrou writes:

It's not only the marketing. Having both releases in lock step means the development process is synchronized between trunk and py3k, that there is no loss of developer focus, and that merges/backports happen quite naturally.

As usual, in theory precision is infinite, but in engineering practice it's fuzzy. "Lock step" doesn't mean "as fine as you can split a second"; for 2.6/3.0 a couple of weeks separation is not going to matter. The important thing is to get right back on schedule for releasing 2.7/3.1 together (if that's the plan). Split-second precision does matter for marketing, though.<wink>

On Mon, Sep 8, 2008 at 7:07 PM, Raymond Hettinger <python@rcn.com> wrote:

[Guido van Rossum]

...

Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway).

With the extra time, it would be worthwhile to add dbm.sqlite to 3.0 to compensate for the loss of bsddb so that shelves won't become useless on Windows builds.

So get started already! :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/)

skip@pobox.com wrote:

Raymond> With the extra time, it would be worthwhile to add dbm.sqlite Raymond> to 3.0 to compensate for the loss of bsddb so that shelves Raymond> won't become useless on Windows builds.

My vote is to separate 2.6 and 3.0 then come back together for 2.7 and 3.1. I'm a bit less sure about adding dbm.sqlite. Unless Josiah's version is substantially faster and more robust I think my version needs to cook a bit longer. I'm just not comfortable enough with SQLite to pronounce my version fit enough. I only intended it as a proof-of-concept, and it's clear it has some shortcomings.

Given that the *API* is fixed though, it is probably better to have the module present in 3.0 and bring it back to the main line in 2.7. If any absolute clangers from a performance/stability point of view get past Raymond (and everyone else with an interest in this) then they can be addressed in 3.0.1 in a few months time. Whereas if we leave the module out entirely, then 3.0 users are completely out of luck until 3.1 (or have to download and possibly build pybsddb). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

Guido van Rossum schrieb:

...

...

Perhaps it's time to separate the 2.6 and 3.0 release schedules? I don't care if the next version of OSX contains 3.0 or not -- but I do care about it having 2.6.

I'm not really sure what good that would do us unless we wanted to bring 3.0 back to the beta phase and continue to work on some larger issues with it. I also suspect doing two separate, but close together final releases would be more stressful than having them in lock and step.

Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway).

Even if I can't contribute very much at the moment, I'm still +1 to that. I doubt Python would get nice publicity if we released a 3.0 but had to tell everyone, "but don't really use it yet, it may still contain any number of showstoppers."

...

Just my pocket change, though.

I'm suspecting this is much more than $0.02 :D Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sep 8, 2008, at 7:25 PM, Guido van Rossum wrote:

Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway).

The MajorOS Vendor (tm) may be willing to ship a 3.0 beta if it's far enough along, though not as the primary Python version. They clearly want 2.6 for that. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZ4cXEjvBPtnXfVAQL4ygP/fLILvf3NhvmN3R2T7htGm08xt/bOBYGt +BDrV4rapS4j3jo2Cx+McEdjJZCdq9x7BIaTN+4ITwq02LEY5fmhp6NkhzE1dlnq qdgBq8x/Z4AnsxfydtqYrPhrzLWPpdEZElgll5FB6Dj6XIA7cB8tuds2cE7+OXJI Guom1Y0k6Ao= =u4FB -----END PGP SIGNATURE-----

On Sep 8, 2008, at 1:13 PM, "Guido van Rossum" <guido@python.org> wrote:

On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <barry@python.org> wrote:

...

I don't think there's any way we're going to make our October 1st goal. We have 8 open release critical bugs, and 18 deferred blockers. We do not have a beta3 Windows installer and I don't have high hopes for rectifying all of these problems in the next day or two.

I propose that we push the entire schedule back two weeks. This means that the planned rc2 on 17-September becomes our rc1. The planned final release for 01-October becomes our rc2, and we release the finals on 15- October.

- -Barry

Perhaps it's time to separate the 2.6 and 3.0 release schedules? I don't care if the next version of OSX contains 3.0 or not -- but I do care about it having 2.6.

Given that 2.6 is going to be more widely adopted and used by both the community and OS distributors, I'm +1 on splitting the releases as well. -Jesse

Barry> 3777 long(4.2) now returns an int Looks like Amaury has already taken care of this one. Skip

On Sun, Sep 07, 2008 at 12:02:06PM -0400, Barry Warsaw wrote:

There are 8 open release blockers, a few of which have patches that need review. So I think we are still not ready to release rc1. But it worries me because I think this is going to push the final release beyond our October 1st goal.

Should we try to schedule a bug evening some time this week? --amk