-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Aug 12, 2008, at 2:44 PM, Martin v. Löwis wrote:
I am planning to offer a single file patch for 2.3 and 2.4. As
far as one more 2.5 release, I don't think there's going to be many
changes to the 2.5 branch between now and 2.6/3.0 final - although if there is, we'll obviously have to do another release.I would like to establish a tradition where, after some final bug
fix release (e.g. for 2.5), further "mere" bug fixes are banned from the maintenance branch (and I did revert several bug fixes from the 2.4 branch).I'm not sure I agree with this policy. Can you elaborate on /why/
you want this?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.
An alternative would be to keep all infrastructure up and running, but that is infeasible.
Or to adopt tools that help improve reliability. I'm not convinced
that the buildbots really do that. A PQM-style approach, while more
of a pain for developers because of the serialized landings, would
definitely improve things, and there's not nearly as much
infrastructure involved to keep humming for old releases. PQM isn't
perfect, but I do believe it would help.
I understand that we're a volunteer organization, and that our
resources are limited. I'm also wary about siphoning off those limit resources right now for working on other than 2.6 and 3.0, but I'm not sure
that this policy really buys us much there. E.g. with this policy you'll
need a release cop to patrol commits and back out non-security fixes right away.That's not necessary. When I made 2.3.7 and 2.4.5, I went through the complete log, and posted a list of patches that I wanted to revert. This was little effort, and I'm sure it would have been even less
effort if people had known that 2.4.x is a closed branch.
I'm glad it wasn't much effort. Would you propose using technological
means to close the branch?
It's much more work to revert such changes whenever we get around to doing the release. Seems like it could be /more/ work with this
policy.It wasn't really that much work - there were little non-security patches, and they were easily identifiable from the commit message.
I do agree that we need to be very careful about introducing new features, but I think non-security patches can be okay.
They aren't, as they don't get sufficient testing.
Again, I don't think that's qualitatively much different for security
patches. We may manually test them, inspect them, rely on vendors to
have tested them, but they don't go through the Q/A process we enforce
for our active branches.
It's demoralizing to have one's patches backed out. Besides, we still
have downstream vendors that are maintaining and releasing Python 2.4;
does this mean they're out of luck for bug fixes or they have to roll
their own?I've talked to the downstream vendors, and they really want security patches for a long time, above all. They are fine with maintaining
their own patches (which they do, anyway).
Would a policy of security-patches-only have any effect on vendors
sharing fixes with us? By that I mean, if 2.4 were open to non-
security patches, would they be more or less willing to feed them
upstream, where we could, if someone were motivated, port them forward?
We're on an 18 month release schedule, which is a long time to
wait, so I'm not in favor of an arbitrary date for cutting off "mere" bug
fixes. Rather, I'd like to see a policy (but not a promise) of supporting
two releases at a time.I think this requires more resources than we have - especially with your way of counting:
Thus, when 2.6 is released, we would stop support for all but critical security fixes for 2.4, but we could (not will) still release bug fixes for 2.5. And of course, we'll support
2.6/3.0 while 2.7/3.1 is being developed.So that's *three* branches that we need to maintain, right: 2.5, 2.6, and 3.0. Once 3.1 is released, I supposed it's even *four* branches: 2.6, 2.7, 3.0, and 3.1. That means that every change must be committed/merged four times, you need to run the test suite four
times, and so on. Depending on the nature of the bug fix, you also need to keep the specifics of the four branches in mind.I don't think our committers will accept such a work load - which
means that some patches don't get backported (arbitrarily, depending on how relevant the committer views that policy).
Let me emphasize that I'm not suggesting our committers do this. I'm
suggesting that if a specific committer is motivated to fix a non-
security bug in an older release, they would have to accept this
responsibility. Maybe it'll never happen because no one really cares
enough. But a policy against it would /prevent/ it even if there was
motivation to do it.
Having lockstep 2.x and 3.x release complicates things a bit, but because they are lockstep, I'm thinking of them more as the same
release rather than separate ones.I think this is an illusion. When did you last commit something to the trunk, and forward-ported it to the 3.0 branch? When did you last run "svnmerge avail"? Porting patches between 2.6 and 3.0 is anything but trivial.
I'll concede that it's very difficult.
- -Barry