On Tue, Mar 4, 2014 at 8:33 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Tue, 04 Mar 2014 11:16:41 +0100 > mar...@v.loewis.de wrote: > > > > Quoting Nick Coghlan <ncogh...@gmail.com>: > > > > > If you don't want to do an rc3 despite the cherry picked changes since > > > rc2, then you need to make it easy for people to test the changes > > > directly from the release branch. An opaque intermittently updated > > > tarball is not acceptable when none of our infrastructure is designed > > > to work that way. I was OK with just the tarball when I assumed you > > > would an rc3 if non-trivial defects were found in rc2. If that's not > > > the case, then we *need* a public mirror of your release clone. > > > > Another rc or not - I expect to see a 3.4.1 release *really* shortly > after > > the 3.4.0 release. So except for issues where Python does not work at > all, > > any glitches that remain in the code can be fixed in the bug fix release. > > I agree with Martin. At this point, we'd better release 3.4.0 (fixing > any critical regressions, but leaving non-critical ones aside), then > patiently collect evidence of issues, and fix them in non-rush > mode for 3.4.1. > How about this (if Larry is amenable): critical now/this week (e.g. pip on Windows works), non-critical in 3.4.1 with Larry aiming to release 3.4.1 by the end of April? That way the PyCon sprints can be used by projects to test against 3.4.1 and the core sprint can work on squashing any bugs that will inevitably come up from 3.4.0 being out the door. This also lets us make our stated 3.4.0 release date. Every release we feel pressure to squeeze on those last few bugs and this release is the same. Heck, you can say it's enhanced as we had a longer rc cycle. Normally the bugs from Armin and Mike -- which I appreciate -- would have just happened after 3.4.0 went out the door and thus be rolled into 3.4.1 anyway. I suspect the community in general views *.0 releases as stable but not perfect while *.1 releases as the solid one where no surprises will pop up because of new code. I have also filed http://bugs.python.org/issue20851 to make sure the devguide covers running tests from a tarball. If the way the release has been handled has still bugged you enough it can be discussed at the language summit, but it would be the first time we consider putting any restrictions on the RM (which I would loathe to do; I'm fine with nudging Larry to do his stuff in public next time in hopes he's more comfortable with the whole process, but I wouldn't want to require it).
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
