On Oct 13, 2009, at 10:15 PM, Martin v. Löwis wrote:
So, we can either make Sunday's release rc2 and do the final
release one
week later, or I can try to get an rc2 out in the next day or two,
with
a final release mid-next week.
Thoughts?
I won't be able to produce Windows binaries until
I strongly urge another release candidate. But then, I am not doing the
work, so take that advice for what it is...
On Oct 14, 2009 10:18 AM, "Barry Warsaw" wrote:
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that
the idea of a release ...
No, but let's do one anyway!
> So, we can either make Sunday's release rc2 and do the final release one
> week later, or I can try to get an rc2 out in the next day or two, with
> a final release mid-next week.
>
> Thoughts?
I won't be able to produce Windows binaries until Saturday. Now sure how
that would fit into the "wit
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote:
I always thought that the idea of a release candidate was that if
there
were any fixes _at all_ that there would be a new rc. Only when no
bugs needing fixed are found does the rc turn into the actual
release.
This was also my understand
On Tue, Oct 13, 2009 at 5:16 PM, Tarek Ziadé wrote:
> On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote:
>> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>>>
>>> Are we on track to release 2.6.4 final this Sunday or do we need
>>> another rc?
>>>
>>> Yesterday, Tarek committed another setuptool
> I always thought that the idea of a release candidate was that if there
> were any fixes _at all_ that there would be a new rc. Only when no
> bugs needing fixed are found does the rc turn into the actual release.
This was also my understanding; that's the point of calling it
"candidate". Sinc
On Oct 13, 2009, at 2:00 PM, Guido van Rossum wrote:
Traceback (most recent call last):
File "umbrella_rules.py", line 6, in
UmbrellaRule()
File "unbrella_rules.py", line 4, in UmbrellaRule
raise
DuplicateRuleName('http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules
On Tue, Oct 13, 2009 at 10:45 AM, Barry Warsaw wrote:
> On Oct 13, 2009, at 1:41 PM, R. David Murray wrote:
>
>> I always thought that the idea of a release candidate was that if there
>> were any fixes _at all_ that there would be a new rc. Only when no
>> bugs needing fixed are found does the r
Barry Warsaw wrote:
> On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote:
>
>> Would it be reasonable to shorten that period, if the fix for the
>> mentioned problem gets ready for prime time earlier ?
>
> I think there are many 2.6.x bugs queued up for after 2.6.4 is
> released. I'm not at all op
On Oct 13, 2009, at 1:41 PM, R. David Murray wrote:
I always thought that the idea of a release candidate was that if
there
were any fixes _at all_ that there would be a new rc. Only when no
bugs needing fixed are found does the rc turn into the actual release.
But I understand that this is a
On Tue, 13 Oct 2009 at 12:57, Barry Warsaw wrote:
On Oct 13, 2009, at 11:16 AM, Tarek Ziad? wrote:
I still need to do some more tests, I didn't have time to try the
various projects under win32.
It's planned to night.
The tests are consisting of compiling and insatling a dozain of
projects on l
>> We don't need to wait too long for 2.6.5 though. A few months would be
>> appropriate.
MAL> Would it be reasonable to shorten that period, if the fix for the
MAL> mentioned problem gets ready for prime time earlier ?
I think it would be worthwhile to prioritize all outstanding
On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote:
Would it be reasonable to shorten that period, if the fix for the
mentioned problem gets ready for prime time earlier ?
I think there are many 2.6.x bugs queued up for after 2.6.4 is
released. I'm not at all opposed to setting a date approxi
Barry Warsaw wrote:
> On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote:
>
>> Then I'd suggest to wait another week with 2.6.4 to give you a
>> chance to look at the patch.
>
> That's not a good option, IMO. We have a known broken 2.6.3 out there
> and we owe it to our users to correct our mista
On Oct 13, 2009, at 12:57 PM, Barry Warsaw wrote:
On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote:
I still need to do some more tests, I didn't have time to try the
various projects under win32.
It's planned to night.
The tests are consisting of compiling and insatling a dozain of
projects o
On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote:
I still need to do some more tests, I didn't have time to try the
various projects under win32.
It's planned to night.
The tests are consisting of compiling and insatling a dozain of
projects on linux and win32 (and bith when possible)
Great th
On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote:
Then I'd suggest to wait another week with 2.6.4 to give you a
chance to look at the patch.
That's not a good option, IMO. We have a known broken 2.6.3 out there
and we owe it to our users to correct our mistake and given them the
release
At 05:42 PM 10/13/2009 +0200, M.-A. Lemburg wrote:
FWIW, I've had to change and tweak our mxSetup.py many many
times to get it to work again with new distutils releases and
I expect this to occur even more often now that distutils is
finally being maintained again - and that's good, since I'll
be
"Martin v. Löwis" wrote:
>
>>> As this bug already exists in 2.6.2, I don't think the change is
>>> eligible for 2.6.4.
>>>
>>> In addition, I want to review it, which I won't be able to until
>>> Sunday.
>>
>> Then I'd suggest to wait another week with 2.6.4 to give you a
>> chance to look at the
P.J. Eby wrote:
> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>> Are we on track to release 2.6.4 final this Sunday or do we need
>> another rc?
>>
>> Yesterday, Tarek committed another setuptools related fix and said
>> that he was going to run a bunch of build tests locally. Tarek, how
>>
At 05:16 PM 10/13/2009 +0200, Tarek Ziadé wrote:
Yes the doctest was pretty fuzzy about what is an extension name. It's
will be improved in 2.7.
The current code is doing os.path.join()'s to join the Extension name
with the build path,
leading to the collateral damage you are mentioning. To fix
On Tue, Oct 13, 2009 at 5:30 PM, P.J. Eby wrote:
>
> One identical to test_build_ext_path_with_os_sep, but that explicitly uses a
> '/' (rather than os.sep) will identify the problem I'm referring to, when
> run on Windows.
>
> It's common practice to use /-separated paths in setup scripts, regard
>> As this bug already exists in 2.6.2, I don't think the change is
>> eligible for 2.6.4.
>>
>> In addition, I want to review it, which I won't be able to until
>> Sunday.
>
> Then I'd suggest to wait another week with 2.6.4 to give you a
> chance to look at the patch.
That won't make the chang
On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote:
> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
>>
>> Are we on track to release 2.6.4 final this Sunday or do we need
>> another rc?
>>
>> Yesterday, Tarek committed another setuptools related fix and said
>> that he was going to run a bunch of
"Martin v. Löwis" wrote:
>
>> It would be nice to get this issue resolved out for 2.6.4:
>>
>> http://bugs.python.org/issue4120
>>
>> The problem is that extensions built with 2.6.x will not work
>> when used with a User-only installation of Python on machines that
>> don't already have the MS VC9
At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote:
Are we on track to release 2.6.4 final this Sunday or do we need
another rc?
Yesterday, Tarek committed another setuptools related fix and said
that he was going to run a bunch of build tests locally. Tarek, how
did that go?
FWIW, that change
> It would be nice to get this issue resolved out for 2.6.4:
>
> http://bugs.python.org/issue4120
>
> The problem is that extensions built with 2.6.x will not work
> when used with a User-only installation of Python on machines that
> don't already have the MS VC90 CRT DLLs installed system-wide
Barry Warsaw wrote:
> Are we on track to release 2.6.4 final this Sunday or do we need another
> rc?
>
> Yesterday, Tarek committed another setuptools related fix and said that
> he was going to run a bunch of build tests locally. Tarek, how did that
> go?
>
> Please note that issue 7064 is stil
On Oct 13, 2009, at 8:31 AM, Zvezdan Petkovic wrote:
Excellent. That's exactly what I meant.
I quoted the part of the previous message where you proposed to
review another patch for 2.6.5. I guess it was not very clear that
I'm proposing to review this for 2.6.5 as well. Well, at least
On Oct 13, 2009, at 8:23 AM, Barry Warsaw wrote:
On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote:
On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote:
I want us to be very careful about 2.6.4. This isn't a normal bug
fix release, it's specifically there to remove the brown paper bag
of 2.6.
Are we on track to release 2.6.4 final this Sunday or do we need
another rc?
Yesterday, Tarek committed another setuptools related fix and said
that he was going to run a bunch of build tests locally. Tarek, how
did that go?
Please note that issue 7064 is still open as a release blocker.
On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote:
On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote:
I want us to be very careful about 2.6.4. This isn't a normal bug
fix release, it's specifically there to remove the brown paper bag
of 2.6.3 from our heads. So let's be conservative and fix
Nick Coghlan wrote:
> M.-A. Lemburg wrote:
>>> sys.userdirsuffix
>>> -
>>>
>>> sys.userdirsuffix is an implementation and platform specific string that
>>> is used to construct the path for the user site directory as explained
>>> in PEP 370. The string contains the implementation n
M.-A. Lemburg wrote:
>> sys.userdirsuffix
>> -
>>
>> sys.userdirsuffix is an implementation and platform specific string that
>> is used to construct the path for the user site directory as explained
>> in PEP 370. The string contains the implementation name as well as the
>> versio
34 matches
Mail list logo
