-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Aug 13, 2008, at 7:33 PM, Martin v. Löwis wrote:
Because there won't typically be sufficient testing and release infrastructure to allow arbitrary bug fixes to be committed on the branch. The buildbots are turned off, and nobody tests the release candidate, no Windows binaries are provided - thus, chances are very high that a bug fix release for some very old branch will be *worse* than the previous release, rather than better.
Why is that qualitatively different than a security fix? All the
same conditions apply.
No. The problem being fixed is completely different. For a security
fix, it is typically fairly obvious what the bug being fixed is (in particular, if you look at the recent ones dealing with overflows):
the interpreter crashes without the patch, and stops crashing (but raises an exception instead) with the patch.
That's true of a certain class of bugs, probably mostly in the C
code. I think potential security bugs in Python code will be closer
to "regular" bug fixes.
I'm glad it wasn't much effort. Would you propose using
technological means to close the branch?
They are still open for security patches (well, 2.4 is; under my proposed policy, 2.3 isn't anymore). If people think it's desirable, we could rename the branch, or we could enforce a certain keyword (e.g. "security") in the commit messages.
I was thinking about preventing commits on the branch. Most security
fixes of the type you describe come in through the psrt, and they may
even be embargoed. For a closed branch, you'd open it for the
security patches when the embargo is lifted, make the commits, then
close it again. That would at least be a very strong clue that the
branch is closed :).