Hello!
At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told me that he'd like to collect data about Release Candidates for point releases (3.x.y). The idea is that if these aren't being tested and aren't revealing bugs, it would make sense to stop releasing them.
So, please, if you find any bugs in upcoming Python *3.6.x* release candidates, let me know (or write to Łukasz directly)! If there are no such reports, there will be no 3.7.x RCs.
Also, are these useful for Fedora? Do/should we test 3.x.y RCs? (3.x.0 pre-releases like the current 3.7.0 beta are a different matter; those are obviously useful.)
----- Original Message -----
From: "Petr Viktorin" pviktori@redhat.com To: "Fedora Python SIG" python-devel@lists.fedoraproject.org Sent: Monday, May 21, 2018 1:39:41 PM Subject: Are 3.6.x release candidates useful to find bugs?
Hello!
At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told me that he'd like to collect data about Release Candidates for point releases (3.x.y). The idea is that if these aren't being tested and aren't revealing bugs, it would make sense to stop releasing them.
So, please, if you find any bugs in upcoming Python *3.6.x* release candidates, let me know (or write to Łukasz directly)! If there are no such reports, there will be no 3.7.x RCs.
Also, are these useful for Fedora? Do/should we test 3.x.y RCs? (3.x.0 pre-releases like the current 3.7.0 beta are a different matter; those are obviously useful.) _______________________________________________ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproje...
Haven't thought that angle before thanks for bringing it up. Indeed we test the RC releases of a new major release (e.g. 3.7) as it helps catching bugs early on, but we've never done that for point releases, as those updates do not usually pose any major issues. Of course there have been bugs for which in most cases we backport the fix from the next point release.
So I see two potential outcomes here. Either we change our procedures on updating the point releases and we test the RC ones as well, or we can just say to upstream that from Fedora's POV we don't really bother with the rc point releases. I'm more inclined towards the second option, as the first one is highly dependent on the workload/free cycles at that particular time frame, and combined with the short window between an RC and the actual release, it could strain a lot of resources for not much of a benefit.
I'd like some more opinions on the matter of course.
On 21 May 2018 at 22:09, Charalampos Stratakis cstratak@redhat.com wrote:
So, please, if you find any bugs in upcoming Python *3.6.x* release candidates, let me know (or write to Łukasz directly)! If there are no such reports, there will be no 3.7.x RCs.
So I see two potential outcomes here. Either we change our procedures on updating the point releases and we test the RC ones as well, or we can just say to upstream that from Fedora's POV we don't really bother with the rc point releases. I'm more inclined towards the second option, as the first one is highly dependent on the workload/free cycles at that particular time frame, and combined with the short window between an RC and the actual release, it could strain a lot of resources for not much of a benefit.
Note also that part of Łukasz's proposal was that if a significant regression *was* found in a point release, then the resolution would be to spin a new point release with a fix ASAP. It's just that in such cases, the version numbers involved would be X.Y.Z and X.Y.Z+1 rather than X.Y.Zrc1 and X.Y.Z.
Cheers, Nick.
On 05/21/18 14:43, Nick Coghlan wrote:
On 21 May 2018 at 22:09, Charalampos Stratakis <cstratak@redhat.com mailto:cstratak@redhat.com> wrote:
> So, please, if you find any bugs in upcoming Python *3.6.x* release > candidates, let me know (or write to Łukasz directly)! If there are no > such reports, there will be no 3.7.x RCs. So I see two potential outcomes here. Either we change our procedures on updating the point releases and we test the RC ones as well, or we can just say to upstream that from Fedora's POV we don't really bother with the rc point releases. I'm more inclined towards the second option, as the first one is highly dependent on the workload/free cycles at that particular time frame, and combined with the short window between an RC and the actual release, it could strain a lot of resources for not much of a benefit.Note also that part of Łukasz's proposal was that if a significant regression *was* found in a point release, then the resolution would be to spin a new point release with a fix ASAP. It's just that in such cases, the version numbers involved would be X.Y.Z and X.Y.Z+1 rather than X.Y.Zrc1 and X.Y.Z.
Indeed. Even if we should do more testing in Fedora than we do now (which of course we should!), the RCs aren't really needed -- if the tests fail, we'll fix the bug upstream, get the fix as part of X.Y.Z+1 (which under Łukasz's rule should be released ASAP), and use that.
(Again, prereleases for *feature* releases, such as the current 3.7.0b4, are very useful and should be kept.)
If there is no more discussion on this topic in the next few days, I'll summarize it to Łukasz.
On 21.5.2018 13:39, Petr Viktorin wrote:
Hello!
At PyCon US 2018, Łukasz Langa, the release manager for Python 3.7, told me that he'd like to collect data about Release Candidates for point releases (3.x.y). The idea is that if these aren't being tested and aren't revealing bugs, it would make sense to stop releasing them.
What we might do is to prep the rc bump in copr, mass rebuild everything there to see test failures.
The problem with this approach is that someone has to do this and even if scripted, there are packages, where the test suites:
* fail in copr only (meh) * fail for unrelated updates in rawhide (i.e. glibc)
So all the buildlogs of packages that fail to build would need manual inspection. I don't think we have time/people to do this.
Also, the obvious imperfection here is also the fact that not all bugs are found by running test suites.
What we could do as a minimal effort solution is to prep the rc in pagure PR and at least see the test failures of CPython itself. This could discover problems in the RCs as well as in Fedora. Earlier than now nevertheless. As we generally update to new patch releases, we'd need to fix those failures later anyway.
python-devel@lists.fedoraproject.org
-
Charalampos Stratakis -
Miro Hrončok -
Nick Coghlan -
Petr Viktorin