[Python-Dev] Cherry-pick between Python 3.4 RC2 and final?

[Nick Coghlan]

On 5 Mar 2014 08:15, "Matthias Klose" <doko at ubuntu.com> wrote:
>
> Am 04.03.2014 15:52, schrieb Brett Cannon:
> > 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.
>
> I wouldn't put it this way, but instead ask how to enable the RM to do
this kind
> of work more publicly.  I really would like it more if we can extend our
buildd
> infrastructure to automatically test during the time where the trunk and
the
> release candidates don't match. I am aware that this was never done for
any
> release in the past, but maybe this is something that can be enabled for
3.5.
> But before documenting a process which may change depending on the RM why
not
> try to align the process?

I think it's also the fact that new feature releases are rare and changes
of release manager even more so, meaning there's a fair bit of relearning
involved every time (since what was appropriate a couple of years earlier
may not be appropriate the next time, and we'll usually have new developers
involved that weren't around for the previous release).

While I'd still strongly prefer an rc3, I think we at least need to get the
remaining release blockers sorted in the tracker (either fixing them or
reclassifying them, or else closing them if they're a rejected cherry pick
request) and a tarball or release clone available for core developer and
third party testing.

We won't be able to get people to test the pip integration fixes on Windows
that way (that's one of the reasons I would like an rc3 and don't
understand the apparent desire to avoid one), but we would at least be able
to check that the Flask and Alembic test suites pass.

I'm being fussy about this for two reasons. Firstly, because my view is the
same as Victor's: the time between the last rc and the final release should
be completely uninteresting, with no significant regressions reported
relative to the previous major version (or any such cases clearly being
rare enough to wait for the first maintenance release). Secondly, I care
because I think we need to take into account the social benefits of
ensuring that we treat third party testers as valued members of the release
process by giving them a clear chance to confirm that the problems they
reported have been addressed before we proceed with the release. That third
party testing does help improve the stability of the final release, and
wherever practical, we should be doing our best to encourage it.

For 3.4rc2, the Alembic and Flask test suites both hit clear regression
bugs (one due to pkgutil still calling a now deprecated function, the other
due to a type slot publishing an incorrect signature), and users also found
that upgrading pip on Windows would prevent subsequently uninstalling
CPython.

I can politely ask Mike and Armin to test against a pre-release tarball, or
against the default branch and assure them the patch has been included in
the release tag, but I have no reasonable answer to give them if they ask
"why not just publish an rc3 to make this easy to test?". For the folks
that reported the Windows installer issues, we can't ask them to double
check the fixes at all if we don't do an rc3.

Regards,
Nick.

>
>   Matthias
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140305/a25b35a3/attachment.html>