Hi,
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
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.
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet. Not sure whether a month would help, of course. However, I wouldn't want to migrate to Mercurial between beta releases, for example. The release process probably needs several rounds to adjust to Mercurial, and we aren't even close to switching.
Regards, Martin
On Sun, Jun 27, 2010 at 10:07, "Martin v. Löwis" martin@v.loewis.de wrote:
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet. Not sure whether a month would help, of course. However, I wouldn't want to migrate to Mercurial between beta releases, for example. The release process probably needs several rounds to adjust to Mercurial, and we aren't even close to switching.
Unless some long-term release of some major OS or distro is about to come out and was hoping to include 3.2 (and I don't think any are), I see no harm in postponing. I know I won't mind as I have some additions/deprecations in importlib that are landing in 3.2.
"Martin v. Löwis" wrote:
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet.
+1
Not sure whether a month would help, of course. However, I wouldn't want to migrate to Mercurial between beta releases, for example. The release process probably needs several rounds to adjust to Mercurial, and we aren't even close to switching.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jun 28 2010)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2010-07-19: EuroPython 2010, Birmingham, UK 20 days to go
::: Try our new mxODBC.Connect Python Database Interface for free ! ::::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Jun 28, 2010 at 1:17 PM, M.-A. Lemburg mal@egenix.com wrote:
"Martin v. Löwis" wrote:
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet.
+1
+1
Le dimanche 27 juin 2010 11:17:24, Georg Brandl a écrit :
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
For the 3.2 final, I would like to mark this issue has a blocker:
http://bugs.python.org/issue8611It's not possible to install Python in a non-ASCII directory (eg. user directory, user with a non-ASCII character in its name) on Windows.
I think that nobody noticed this bug before because there are few early adopters (people testing Python3).
I think that #8988 is a duplicate.
Fix #8611 is not trivial. I opened ~20 issues to prepare the work. It's not finished yet.
Victor
On Mon, Jun 28, 2010 at 9:41 PM, Victor Stinner victor.stinner@haypocalc.com wrote:
Le dimanche 27 juin 2010 11:17:24, Georg Brandl a écrit :
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
For the 3.2 final, I would like to mark this issue has a blocker:
I went ahead and marked it as such - the RM reviews the open release blockers anyway before deciding whether or not to make a release, and will either demote them permanently (i.e disagree with the assessment of their importance), defer them (more common for alpha releases than later ones) or delay the release.
We don't want to go crazy with it (the RM shouldn't be getting deluged with trivial issues to review all the time), but if you think something really should be a release blocker, feel free to bump the priority yourself.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Jun 27, 2010, at 01:58 PM, Brett Cannon wrote:
On Sun, Jun 27, 2010 at 10:07, "Martin v. Löwis" martin@v.loewis.de wrote:
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet. Not sure whether a month would help, of course. However, I wouldn't want to migrate to Mercurial between beta releases, for example. The release process probably needs several rounds to adjust to Mercurial, and we aren't even close to switching.
Unless some long-term release of some major OS or distro is about to come out and was hoping to include 3.2 (and I don't think any are), I see no harm in postponing. I know I won't mind as I have some additions/deprecations in importlib that are landing in 3.2.
As it currently stands the next version of Ubuntu, due out in October, will not include Python 3.2. The version after that is due in April, but will be open soon after the October release. Generally, I think it's a good idea to get major new toolchain packages in as early in the cycle as possible, and I'd like to get us on Python 3.2, if we're talking a 3.2b1 by mid October (instead of mid-Sept), with a final release in January, we should be fine I think.
-Barry
On Jun 28, 2010, at 4:17 AM, M.-A. Lemburg wrote:
"Martin v. Löwis" wrote:
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet.
+1
+1
Raymond
Le dimanche 27 juin 2010 à 19:07 +0200, "Martin v. Löwis" a écrit :
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet.
For the record, what are those things?
Am 28.06.2010 23:30, schrieb Antoine Pitrou:
Le dimanche 27 juin 2010 à 19:07 +0200, "Martin v. Löwis" a écrit :
I'm delaying the 3.2 alpha1 release by one week; I don't have enough time to sort through all the possible issues and get acquainted with the release machinery this weekend.
Should we perhaps delay the entire schedule by one month? A number of things that people want for 3.2 haven't happened yet.
For the record, what are those things?
The ones I want to get done are PEPs 382 and 384.
Something I know others want to achieve is the switch to Mercurial. A number of PEPs are targetted for 3.2 with unclear status: 3143, 3144, 3145, 3148.
Regards, Martin
On Tue, Jun 29, 2010 at 3:28 AM, "Martin v. Löwis" martin@v.loewis.de wrote:
The ones I want to get done are PEPs 382 and 384.
Just to have the direct information on these PEPs inline.
PEP 382 - Namespace Packages http://www.python.org/dev/peps/pep-0382/ PEP 383 - Definition of Stable ABI http://www.python.org/dev/peps/pep-0384/
Something I know others want to achieve is the switch to Mercurial. A number of PEPs are targetted for 3.2 with unclear status: 3143, 3144, 3145, 3148.
PEP 3143 - Standard Deamon Process Library http://www.python.org/dev/peps/pep-3143/
PEP 3144 - IP Address Manipulation Library http://www.python.org/dev/peps/pep-3144/
PEP 3145 - Asynchronous I/O for Subprocess.Popen http://www.python.org/dev/peps/pep-3145/
PEP 3148 - futures package http://www.python.org/dev/peps/pep-3148/
Except for the 'futures' package which featured discussion again recently, others have been in a sleeping mode for a while. There is a codeline ( I assume, it is stable) for the above mentioned additions to stdlib maintained outside the svn tree.
-- Senthil
On Jun 28, 2010, at 11:58 PM, Martin v. Löwis wrote:
The ones I want to get done are PEPs 382 and 384.
I'd like to help with these. I remember we had a long thread a few weeks back about PEP 382 (namespace packages) and there are some tricky issues to work out. I need to go back and re-read that thread. Maybe Jason and Eric want to set up another local sprint to attack it again.
Something I know others want to achieve is the switch to Mercurial. A number of PEPs are targetted for 3.2 with unclear status: 3143, 3144, 3145, 3148.
I really think we need to make the switch to Mercurial as soon as 2.7 final is out. It's been long enough.
-Barry
On Tue, Jun 29, 2010 at 15:12, Barry Warsaw barry@python.org wrote:
I really think we need to make the switch to Mercurial as soon as 2.7 final is out. It's been long enough.
I got back into working on it last week (using a branch map to clean up all the feature branches we're going to shed for the conversion), but then it turned out that there is a regression in hgsubversion right now for r21112. It probably has something to do with the fact that this revision was manufactured by cvs2svn.
Additionally, I've been stressing out quite a bit about my master's thesis, which is due in about 4 weeks. So I'm unlikely to spend much time on this during the rest of July, but would be quite happy to get back into it in August.
Also, help would be appreciated with the hgsubversion regression; I can supply a complete traceback.
Cheers,
Dirkjan
On Tue, Jun 29, 2010 at 06:24, Dirkjan Ochtman dirkjan@ochtman.nl wrote:
On Tue, Jun 29, 2010 at 15:12, Barry Warsaw barry@python.org wrote:
I really think we need to make the switch to Mercurial as soon as 2.7 final is out. It's been long enough.
I got back into working on it last week (using a branch map to clean up all the feature branches we're going to shed for the conversion), but then it turned out that there is a regression in hgsubversion right now for r21112. It probably has something to do with the fact that this revision was manufactured by cvs2svn.
Additionally, I've been stressing out quite a bit about my master's thesis, which is due in about 4 weeks.
I'm working on my Ph.D. thesis right now, so I can relate.
So I'm unlikely to spend much time on this during the rest of July, but would be quite happy to get back into it in August.
Also, help would be appreciated with the hgsubversion regression; I can supply a complete traceback.
Can you open a bug on bitbucket for it and post the link here? Since I am in the same boat as you I can't take a look at it myself, but lowering the barrier to trying to tackle should help raise the chances someone has a look.
-Brett
Cheers,
Dirkjan
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
The ones I want to get done are PEPs 382 and 384.
I'd like to help with these. I remember we had a long thread a few weeks back about PEP 382 (namespace packages) and there are some tricky issues to work out. I need to go back and re-read that thread. Maybe Jason and Eric want to set up another local sprint to attack it again.
Help is surely appreciated (but please do keep me involved).
Something I know others want to achieve is the switch to Mercurial. A number of PEPs are targetted for 3.2 with unclear status: 3143, 3144, 3145, 3148.
I really think we need to make the switch to Mercurial as soon as 2.7 final is out. It's been long enough.
I think this really needs a volunteer or more to contribute. I doubt anybody is working on the remaining issues.
I still think we absolutely need to have a test installation that is completely ready with no known issues, up for at least 14 days. So if you want to switch to hg a week after 2.7 gets released, you would have had to bring up that test installation up last weekend.
I don't want to find us in a situation were work is blocked or significantly more difficult just because some significant pieces of infrastructure were not in place when we made the switch.
Regards, Martin
Am 29.06.2010 05:32, schrieb Senthil Kumaran:
On Tue, Jun 29, 2010 at 3:28 AM, "Martin v. Löwis" martin@v.loewis.de wrote:
The ones I want to get done are PEPs 382 and 384.
Just to have the direct information on these PEPs inline.
PEP 382 - Namespace Packages http://www.python.org/dev/peps/pep-0382/ PEP 383 - Definition of Stable ABI http://www.python.org/dev/peps/pep-0384/
PEP 382 would be nice to have.
Something I know others want to achieve is the switch to Mercurial. A number of PEPs are targetted for 3.2 with unclear status: 3143, 3144, 3145, 3148.
PEP 3143 - Standard Deamon Process Library http://www.python.org/dev/peps/pep-3143/
PEP 3144 - IP Address Manipulation Library http://www.python.org/dev/peps/pep-3144/
PEP 3145 - Asynchronous I/O for Subprocess.Popen http://www.python.org/dev/peps/pep-3145/
PEP 3148 - futures package http://www.python.org/dev/peps/pep-3148/
Except for the 'futures' package which featured discussion again recently, others have been in a sleeping mode for a while. There is a codeline ( I assume, it is stable) for the above mentioned additions to stdlib maintained outside the svn tree.
All of these will need to be "finished" and proposed for inclusion officially, before they can be approved.
All in all, hearing the arguments in this thread I agree that a month more time for development is a good thing, and I will update the release schedule accordingly.
Georg
2010/6/30 Georg Brandl g.brandl@gmx.net:
All in all, hearing the arguments in this thread I agree that a month more time for development is a good thing, and I will update the release schedule accordingly.
You could just throw in another alpha. It never hurts to get the code out there IMO.
-- Regards, Benjamin
Le mercredi 30 juin 2010 à 09:43 -0500, Benjamin Peterson a écrit :
2010/6/30 Georg Brandl g.brandl@gmx.net:
All in all, hearing the arguments in this thread I agree that a month more time for development is a good thing, and I will update the release schedule accordingly.
You could just throw in another alpha. It never hurts to get the code out there IMO.
+1.
Am 30.06.2010 16:43, schrieb Benjamin Peterson:
2010/6/30 Georg Brandl g.brandl@gmx.net:
All in all, hearing the arguments in this thread I agree that a month more time for development is a good thing, and I will update the release schedule accordingly.
You could just throw in another alpha. It never hurts to get the code out there IMO.
Yes, but on the other hand probably nobody cares. So I'd rather like to keep the current schedule with 3 months alpha period, especially because there still may be substantial changes during that period.
Georg
participants (13)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Dirkjan Ochtman -
Georg Brandl -
M.-A. Lemburg -
Nick Coghlan -
Raymond Hettinger -
Senthil Kumaran -
Tarek Ziadé -
Victor Stinner