Home Original page

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

Barry Warsaw barry at python.org
Tue Aug 12 14:18:21 CEST 2008 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Aug 12, 2008, at 3:38 AM, Martin v. Löwis wrote:

> Anthony Baxter 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?

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

I do agree that we need to be very careful about introducing new  
features, but I think non-security patches can be okay.

I had some 2.4 patches backed out because they weren't security  
releases.  I was okay with it at the time, but I'm uncomfortable about  
imposing this as a general rule.  If we have bugs, and we have someone  
motivated to fix them, we should opt toward fixing them.  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?

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

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.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKF/jnEjvBPtnXfVAQIQdAQArojNCP9pEwrNxxYQgky5j36nO9buQlP2
c43AmS0xCa+OKK/fL1QEcza1n6B7j1fT/w6Cf429Rtdsh9tNwig5NVJDTuD/5rRg
RXNJiBKsr69uba8ITV/qO8J1hEuew15w6exBXOMnAUpdoXpxafqg2ycoFmK3/C6E
ZAXnDYAgFoc=
=pkeW
-----END PGP SIGNATURE-----
More information about the python-committers mailing list