Hi all,
Now 2.6rc1 is released, shouldn't the issues which have "deferred blocker" status be put back in the "release blocker" category?
cheers
Antoine.
On Sat, Sep 13, 2008 at 7:37 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi all,
Now 2.6rc1 is released, shouldn't the issues which have "deferred blocker" status be put back in the "release blocker" category?
I believe most of those issues are actually 3.0 ones that were demoted to deferred, so we can release 3.0rc1 on Wednesday. I think the ones applicable to 2.6 can be bumped up, though.
cheers
Antoine.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 13, 2008, at 9:12 PM, Benjamin Peterson wrote:
On Sat, Sep 13, 2008 at 7:37 PM, Antoine Pitrou
<solipsis@pitrou.net> wrote:Hi all,
Now 2.6rc1 is released, shouldn't the issues which have "deferred blocker" status be put back in the "release blocker" category?
I believe most of those issues are actually 3.0 ones that were demoted to deferred, so we can release 3.0rc1 on Wednesday. I think the ones applicable to 2.6 can be bumped up, though.
Yes, please bump the 2.6 deferreds to release blockers.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSMyHu3EjvBPtnXfVAQK1yQP+OFOvMCEJOo7y251FCJalDy0pcK/rxZPR b5nuMZ89L8gJ+crM0VAmcWc0KjX/P233jlC+CYtN7VYGp3J1VatRYNJuzbNuAl4V XMF42ykMKYAHHFCM1/0axvTGqkIuunQlaSdxMP4tXoPpMnvQLdagqovAQ2PQT98I 3zk1ZFoxjXo= =084Q -----END PGP SIGNATURE-----
On Sat, Sep 13, 2008 at 10:40 PM, Barry Warsaw <barry@python.org> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 13, 2008, at 9:12 PM, Benjamin Peterson wrote:
On Sat, Sep 13, 2008 at 7:37 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
Hi all,
Now 2.6rc1 is released, shouldn't the issues which have "deferred blocker" status be put back in the "release blocker" category?
I believe most of those issues are actually 3.0 ones that were demoted to deferred, so we can release 3.0rc1 on Wednesday. I think the ones applicable to 2.6 can be bumped up, though.
Yes, please bump the 2.6 deferreds to release blockers.
I just tried.
You'll all be happy to know that we have no 2.6 deferred blockers. :) Maybe, I should bump some other ones up, so we feel stressed enough...
-- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."
You'll all be happy to know that we have no 2.6 deferred blockers. :)
I thought this was the plan from the beginning: make sure that for rc1, there aren't any blockers - not even deferred ones. All 3.0 blockers got deferred before 2.6rc1, but the 2.6 blockers stayed.
In case you wonder where they all went - I "resolved" a number of them by declaring that they shouldn't really block the release; in most cases, people then agreed (or didn't object).
As a criterion, I asked "could that get fixed in 2.6.1 as well?", and I thought it could if
- it's not a regression wrt. 2.5, and
- it's not really that embarrassing, and
- fixing it won't violate the policies that we had established for bug fix releases.
It's the latter point I'd like to get more feedback on: for a few issues, I declared them as non-blockers because they dealt with the addition of -3 warnings, or lib2to3 additions.
I would claim that it is fine if both 2to3 fixers and -3 warnings get added to 2.6.1, even though they are strictly-speaking new features. For 2to3, it should be fairly obvious: most of the time, adding fixers just means that you have to do less work. There is a small chance, of course, that adding a fixer may break conversion for a code base for which conversion previously worked. Still, since conversion is mostly a manual process, developers invoking it will still be able to deal with that.
For -3 warnings, I would also assume that people normally don't run Python with -3 (i.e. in production), but do so only if they actually look into porting to 3.0. Adding a warning will then let them find out problems more quickly which they would otherwise need to find out the hard way, so I also don't see how adding such warnings could cause problems.
Of course, if people disagree with these principles, it means that we either a) have those changes block 2.6 again, until they get resolved, or b) defer the change to 2.7. For 2to3 in particular, it would mean that the built-in version of 2to3 wouldn't change until 2.7 (except for clear bug fixes).
Regards, Martin
On Sun, Sep 14, 2008 at 9:58 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
You'll all be happy to know that we have no 2.6 deferred blockers. :)
I thought this was the plan from the beginning: make sure that for rc1, there aren't any blockers - not even deferred ones. All 3.0 blockers got deferred before 2.6rc1, but the 2.6 blockers stayed.
In case you wonder where they all went - I "resolved" a number of them by declaring that they shouldn't really block the release; in most cases, people then agreed (or didn't object).
Great -- thanks!
As a criterion, I asked "could that get fixed in 2.6.1 as well?", and I thought it could if
- it's not a regression wrt. 2.5, and
- it's not really that embarrassing, and
- fixing it won't violate the policies that we had established for bug fix releases.
It's the latter point I'd like to get more feedback on: for a few issues, I declared them as non-blockers because they dealt with the addition of -3 warnings, or lib2to3 additions.
I would claim that it is fine if both 2to3 fixers and -3 warnings get added to 2.6.1, even though they are strictly-speaking new features. For 2to3, it should be fairly obvious: most of the time, adding fixers just means that you have to do less work. There is a small chance, of course, that adding a fixer may break conversion for a code base for which conversion previously worked. Still, since conversion is mostly a manual process, developers invoking it will still be able to deal with that.
I would go further -- I don't see the fixers in 2to3 as part of the distribution in the same way as I see other library code. That is, in a sense I find it awkward that the fixers are all contained in the Lib tree -- this part of 2to3 feels like an application, not really a library, and clearly we should be doing all we can to improve the set of fixers over time! OTOH the APIs used to create fixers and to use lib2to3 for another purpose (e.g. for a hypothetical 3-to-2 converter or other transformations) should be considered as part of the standard library -- there's a lot of reusable code there!
For -3 warnings, I would also assume that people normally don't run Python with -3 (i.e. in production), but do so only if they actually look into porting to 3.0. Adding a warning will then let them find out problems more quickly which they would otherwise need to find out the hard way, so I also don't see how adding such warnings could cause problems.
This isn't so clear-cut as 2to3 fixers, but I think it is worthwhile to exempt -3 warnings from the "no new features" requirement, and instead to try to add more -3 warnings (and possibly remove or change existing ones) over time as we learn more about the subtleties of translating 2.6 code to 3.0.
Of course, if people disagree with these principles, it means that we either a) have those changes block 2.6 again, until they get resolved, or b) defer the change to 2.7. For 2to3 in particular, it would mean that the built-in version of 2to3 wouldn't change until 2.7 (except for clear bug fixes).
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Martin v. Löwis wrote:
It's the latter point I'd like to get more feedback on: for a few issues, I declared them as non-blockers because they dealt with the addition of -3 warnings, or lib2to3 additions.
Allowing both of those in 2.6.1 seems reasonable to me - and if any of the 2to3 fixers seems potentially problematic, then we can put them in the 'disabled by default' category.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
http://www.boredomandlaziness.org-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sep 14, 2008, at 12:58 PM, Martin v. Löwis wrote:
I thought this was the plan from the beginning: make sure that for
rc1, there aren't any blockers - not even deferred ones. All 3.0 blockers got deferred before 2.6rc1, but the 2.6 blockers stayed.In case you wonder where they all went - I "resolved" a number of them by declaring that they shouldn't really block the release; in most cases, people then agreed (or didn't object).
As a criterion, I asked "could that get fixed in 2.6.1 as well?", and I thought it could if
- it's not a regression wrt. 2.5, and
- it's not really that embarrassing, and
- fixing it won't violate the policies that we had established for bug fix releases.
Martin, I agree with your take on this, and Guido's follow up. Thanks.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin)
iQCVAwUBSM5keHEjvBPtnXfVAQIGugQAkYDZatppkBTysc1+wJ1raamgBdIqFXA/ +/jUiEv6dRHIhfu+CqAhCD+M8h5sWl2iZ+VZaHqvgiJdv7nU1Zd+oQCp4Iw42rOP Eqy/bR1euBO3tQxqrq5UyFVZjCuYEIvwJP0odiFoa/ygc7J7/yuu2EEysG97Xgo7 urZRlZO2UGw= =T3PN -----END PGP SIGNATURE-----
Le samedi 13 septembre 2008 à 20:12 -0500, Benjamin Peterson a écrit :
I believe most of those issues are actually 3.0 ones that were demoted to deferred, so we can release 3.0rc1 on Wednesday.
I'm not sure I understand. I thought the 3.0 release blockers were demoted to deferred blockers so that we could release 2.6rc1, not 3.0rc1... Otherwise it seems to defeat the whole point of having release blockers.
(perhaps I'm just lacking coffee)
participants (6)
-
"Martin v. Löwis" -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Guido van Rossum -
Nick Coghlan