<p dir="ltr"><br>
On 5 Mar 2014 08:15, "Matthias Klose" <<a href="mailto:doko@ubuntu.com">doko@ubuntu.com</a>> wrote:<br>
><br>
> Am 04.03.2014 15:52, schrieb Brett Cannon:<br>
> > I have also filed <a href="http://bugs.python.org/issue20851">http://bugs.python.org/issue20851</a> to make sure the<br>
> > devguide covers running tests from a tarball. If the way the release has<br>
> > been handled has still bugged you enough it can be discussed at the<br>
> > language summit, but it would be the first time we consider putting any<br>
> > restrictions on the RM.<br>
><br>
> I wouldn't put it this way, but instead ask how to enable the RM to do this kind<br>
> of work more publicly.  I really would like it more if we can extend our buildd<br>
> infrastructure to automatically test during the time where the trunk and the<br>
> release candidates don't match. I am aware that this was never done for any<br>
> release in the past, but maybe this is something that can be enabled for 3.5.<br>
> But before documenting a process which may change depending on the RM why not<br>
> try to align the process?</p>
<p dir="ltr">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).</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">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.</p>

<p dir="ltr">Regards,<br>
Nick.</p>
<p dir="ltr">><br>
>   Matthias<br>
><br>
> _______________________________________________<br>
> Python-Dev mailing list<br>
> <a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
> <a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
> Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com">https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com</a><br>
</p>