[Python-Dev] Python 2.6.5
Antoine Pitrou
solipsis at pitrou.net
Wed Feb 10 07:25:13 CET 2010
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 that we don't
> want to release Python if there are known ways of crashing it, but I
> think that would be useless as it would mean that we can't make any
> releases for the next five years or so
It really boils down to what kind of crasher it is.
When it is triggered by giving 24 instead of 23 as an argument to
time.asctime() (i.e. a simple off-by-one error), it is more severe than
a crasher which can only be triggered through artificially convoluted
code.
> So the policy that I would suggest to follow instead is that known
> crashes (and other "serious" bugs, like incompatibilities, or failures
> to build) can block releases only if they are regressions, or if the
> release manager decides to make them release blockers.
I disagree with the idea that the severity of a bug is correlated with
it being a regression. If e.g. a critical security problem is found, it
has to be corrected even though it may have been present for 5 years in
the source.
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.
Regards
Antoine.
More information about the Python-Dev
mailing list