I just verified with our ActivePython build that 2.6.4rc2 builds fine on Linux,
Windows, Mac, HP-UX, AIX and Solaris. 3.1.2rc1 builds fine except on AIX[1] and
HP-UX[2] but those issues existed in 3.1.1 too, I believe.
-srid
[1] http://bugs.python.org/issue6645
[2] http://bugs.python.org/issue5
Le Thu, 11 Feb 2010 10:36:22 -0500, Barry Warsaw a écrit :
>
> Unless other details come to light, I agree. This one isn't worth
> holding up the release for.
Ok, since everyone seems to agree on this, I've downgraded the priority
of the issue. Thanks for an insightful discussion :-)
cheers
A
On Feb 11, 2010, at 10:05 PM, Nick Coghlan wrote:
>When I've kicked issues in the RM's direction for a decision, I've
>generally tried to make sure my last comment makes it clear exactly what
>decision I'm asking them to make.
Yes, this is an *excellent* point!
-Barry
signature.asc
Description
On Feb 10, 2010, at 11:46 PM, Martin v. Löwis wrote:
>That would require that Barry actually *can* judge the issue at hand. In
>the specific case, I would expect that Barry would defer the specifics
>of the Windows issue to Windows experts, and then listen to what they
>say.
Yep, absolutely.
>I'
Martin v. Löwis wrote:
>> If a committer or triage
>> person sets an issue to release blocker it should mean that they think
>> the release manager should make a decision about that issue before the
>> next release. That decision may well be that it shouldn't be a blocker.
>
> I think it's (sligh
Antoine Pitrou wrote:
> As for setting keywords, there doesn't seem to be much you could have an
> authority to decide as a non-committer. You might think (and perhaps with good
> reason) that the patch is ready for commit into the SVN, but it's precisely a
> committer's job to decide that.
There
> If a committer or triage
> person sets an issue to release blocker it should mean that they think
> the release manager should make a decision about that issue before the
> next release. That decision may well be that it shouldn't be a blocker.
I think it's (slightly) worse. For the release man
On Wed, 10 Feb 2010 13:57:31 +0200, anatoly techtonik
wrote:
> On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote:
> >
> > Besides, as Barry said, classifying a bug as blocker is also a good way
> > to attract some attention on it. Other classifications, even "critical",
> > don't have the sa
On Tue, Feb 9, 2010 at 21:24, Barry Warsaw wrote:
> On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
>
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608 Is i
On Feb 10, 2010, at 01:57 PM, anatoly techtonik wrote:
>Unfortunately, not many people have privilege to change bug properties
>to attract attention to the issues. For example, this patch -
>http://bugs.python.org/issue7582 is ready to be committed, it is
>trivial, not a release blocker, but would
anatoly techtonik writes:
> Is it possible to make exploits out of crashers?
Depends on how you define "exploit". If your definition includes
denial of service, yes, crashing a server application would count.
Privilege escalation is harder to achieve. The general answer is
"yes", but each cas
Antoine Pitrou writes:
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
If done for the sole purpose of attracting attention, it's no
different from spam. Opinions
anatoly techtonik gmail.com> writes:
>
> Unfortunately, not many people have privilege to change bug properties
> to attract attention to the issues. For example, this patch -
> http://bugs.python.org/issue7582 is ready to be committed, it is
> trivial, not a release blocker, but would be nice be
On Wed, Feb 10, 2010 at 8:25 AM, Antoine Pitrou wrote:
>
> Besides, as Barry said, classifying a bug as blocker is also a good way
> to attract some attention on it. Other classifications, even "critical",
> don't have the same effect.
Unfortunately, not many people have privilege to change bug p
Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit :
>
> Maybe I'm being pedantic, but I really think there should be more
> objective criteria for such things.
Well we could try to find objective criteria but I'm not sure we'll find
agreement on them.
> We could set a policy
anatoly techtonik gmail.com> writes:
>
> Is it possible to make exploits out of crashers?
It depends which ones. If it's something like a buffer overflow or a memory
management problem, it may be possible to exploit it through carefully crafted
input (in order to make the interpreter execute arb
> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608 Is it ok to release new versions
that are kn
On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
>
> Is it possible to make exploits out of crashers?
The crashers involve creating convoluted python code,
but then if you're in a position to execute arbitrary
Python code, then you don't have to resort to any
tricks to do something nasty wit
On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis" wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>>> that are known to
On Feb 9, 2010, at 5:20 PM, Martin v. Löwis wrote:
> Of course, the release manager can always declare anything a release
> blocker, so that may have been the reason (I don't recall the details).
I should probably clarify my last statement. I will sometimes mark an issue
"release blocker" becau
On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>>> that are known to crash?
Antoine Pitrou wrote:
> Martin v. Löwis v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn't be
>> blocked.
>
> I think
Martin v. Löwis v.loewis.de> writes:
>
> IOW, I feel that release blockers should only be used if something
> really bad would happen that can be prevented by not releasing. If
> nothing actually gets worse by the release, the release shouldn't be
> blocked.
I think most blocking bugs we've had
>>> I've changed this issue to release blocker. What are the other issues?
>> For a bug fix release, it should (IMO) be a release blocker *only* if
>> this is a regression in the branch or some recent bug fix release over
>> some earlier bug fix release.
>
> As far as I remember, I think we have h
Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit :
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> >> that
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>> that are known to crash?
>
> I've changed this issue to release blocker. What a
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new
> versions that are known to crash?
As a general principle: yes, that's ok. We even distribute known
crashers with every release.
Regards,
Martin
___
On Tue, Feb 9, 2010 at 06:45, anatoly techtonik wrote:
> On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou
> wrote:
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >>
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org
On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou wrote:
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608 Is it ok to release new versions
>> that are known to cra
Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608 Is it ok to release new versions
> that are known to crash?
I've changed this issue to release blocker. What are the
On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.
On Feb 4, 2010, at 4:59 AM, Barry Warsaw wrote:
> I still think this should go in 2.6.5. The patch does not apply to the
> current 2.6 branch because of changes in setup.py. If the patch is ported,
> reviewed and works with no regressions (when libreadline is both installed on
> OS X 10.5 and
On Feb 03, 2010, at 11:50 PM, Ronald Oussoren wrote:
>> Barry's answer was "yes" back in October.
>
>I will backport the patch if Barry says it's fine. Feel free to ping me if
>that doesn't happen before the end of next week.
I still think this should go in 2.6.5. The patch does not apply to th
On 3 Feb, 2010, at 21:27, Zvezdan Petkovic wrote:
> On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
>
>>> This patch is still waiting a review and backporting from trunk.
>>>
>>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>>>
>>> Can we get it in?
>>
>> Only if on
On Feb 3, 2010, at 3:07 PM, Martin v. Löwis wrote:
>> This patch is still waiting a review and backporting from trunk.
>>
>> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>>
>> Can we get it in?
>
> Only if one of the Mac people checks it in.
It's already checked in the
> This patch is still waiting a review and backporting from trunk.
>
> http://mail.python.org/pipermail/python-dev/2009-October/092771.html
>
> Can we get it in?
Only if one of the Mac people checks it in. As they are *REALLY* scarce,
the answer is probably "no".
I'd offer a special version of
On Feb 2, 2010, at 1:08 PM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.6.
+1
On Feb 2, 2010, at 10:08 AM, Barry Warsaw wrote:
> I'm thinking about doing a Python 2.6.5 release soon. I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on
38 matches
Mail list logo
