-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSKNhKnEjvBPtnXfVAQLC1AP8D4aJqfpEVCDt2I70wbiBLX+U2AL4LzmS
B08/pfWwZ1XdCRtx9Fp0MqVuTqpaKMJXXkA3zq6gxOQW1MQOi/ubWYkUlQYc/JMz
ZZUwm+jmccc+YeD5jffFM7HDuPK0hyHmK9MaS8blwXddQBiMIeJ/8u7gGmZGVN81
4FNjnwz1c1s=
=RBUx
-----END PGP SIGNATURE-----
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
