[python-committers] [Python-Dev] next beta

[Barry Warsaw]

-----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-----