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

["Martin v. Löwis"]

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

An alternative would be to keep all infrastructure up and running,
but that is infeasible.

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

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

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

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

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

Regards,
Martin