[python-committers] deferred blockers

"Martin v. Löwis" martin at v.loewis.de
Sun Sep 14 18:58:32 CEST 2008

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


More information about the python-committers mailing list