-----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-----
_______________________________________________
python-committers mailing list
python-committers@python.org
http://mail.python.org/mailman/listinfo/python-committers
