On 05/21/18 14:43, Nick Coghlan wrote:
On 21 May 2018 at 22:09, Charalampos Stratakis
<cstratak(a)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.