-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 13, 2008, at 7:11 PM, Martin v. Löwis wrote:
There's a difference between never being released, and unavailable in
the source repository.
So would you have preferred if I had forked another branch that still
contained these patches? Such branch can still be added now. Nothing
that gets added to the source repository ever becomes unavailable.
Re-adding them is fairly easy: they are all in r61179.
Sure, but nobody's going to dig through commit messages to dig out
those patches.
I'm not sure what I would have preferred. Really, I was mostly fine
with the decision to do as we did. But if we stick with the policy
you propose (which I'm not sure is completely nailed down yet), then I
will be sure not to waste my time on closed releases next time.
Going forward, the question would then be if these patches will ever
get released. So there could be two branches, one that people can
commit
arbitrary bug fixes to (which will never be released), and one that
gets security patches (which will get released for five years).
Of course, I would personally find it fairly confusing to have people
commit patches that are explicitly will not be released, and still
aren't experimental or private-use.
No, I don't think we need another branch per version.
I'm clearly in the minority, and I've said my peace on the subject, so
I'll let it go. Moving forward, I do want to make sure we communicate
to our users and developers, exactly what the policy is, with enough
advanced warning for each version so that they can plan ahead and
won't waste time. Ideally, we would lay this out when we plan the
release.
For example, let's project dates for closing 2.6 and 3.0 now, and add
them to PEP 361.
- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSKOvzXEjvBPtnXfVAQImrAP+IZHk711jPL8GdfrFiENt0KgGD5vjjg/g
kxgBsyVWi/wOonM0cFUABzSxBzfCOPd1eWtD54bs4rk32sXA+v3qtoHKylPsv/0O
8WUq4dXZ3LLn7D50WKWrJNIKTlAaxoH+OWCKK+qgaCEFhv/uKAISaeAxADh2vlzK
YQmkz//7Jjs=
=GTEP
-----END PGP SIGNATURE-----
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
