Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x
We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter. Assuming no release-blocker issues arise during the release candidate testing, 3.7.8 and 3.6.11 will release on 06-27. https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-releas... -- Ned Deily nad@python.org -- []
Why not take a look at the list of open issues for 3.7 with PRs then? There are 702 as of now. https://bugs.python.org/issue?%40sort0=creation&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cversions%2Cstage&status=1&versions=21&stage=4&%40pagesize=50&%40startwith=0 On 12.06.2020 11:17, Ned Deily wrote:
We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter. Assuming no release-blocker issues arise during the release candidate testing, 3.7.8 and 3.6.11 will release on 06-27.
https://discuss.python.org/t/upcoming-cutoffs-for-3-9-3-8-3-7-and-3-6-releas...
-- Ned Deily nad@python.org -- [] _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EKYBL5VG... Code of Conduct: http://python.org/psf/codeofconduct/ -- Regards, Ivan
On Jun 12, 2020, at 08:25, Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
Why not take a look at the list of open issues for 3.7 with PRs then? There are 702 as of now.
Looking at open PRs is a good suggestion. Unfortunately, the version tags on the bug tracker are not consistently maintained and updated. Just because there is a PR attached to an issue doesn’t mean that it would be applicable today to all the versions selected in the issue. A more accurate approach is to look at open PRs that are either explicitly targeted for 3.7 or which have the “needs backport to 3.7” label. By those metrics, we currently have no open 3.7-specific PRs (the last was merged yesterday) and there are 60 open PRs with the 3.7 backport label. But even that number is high because some of those will end up not getting merged to master at all, and thus not backported, and others will be merged to master for 3.10 and perhaps to 3.9 but deemed inappropriate to backport to 3.8 and/or 3.7. https://github.com/python/cpython/pulls?utf8=✓&q=is%3Apr+is%3Aopen+base%3A3.7 https://github.com/python/cpython/pulls?utf8=✓&q=is%3Apr+is%3Aopen+label%3A%22needs+backport+to+3.7%22 -- Ned Deily nad@python.org -- []
On 12.06.2020 16:08, Ned Deily wrote:
On Jun 12, 2020, at 08:25, Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
Why not take a look at the list of open issues for 3.7 with PRs then? There are 702 as of now.
https://bugs.python.org/issue?%40sort0=creation&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cversions%2Cstage&status=1&versions=21&stage=4&%40pagesize=50&%40startwith=0 Looking at open PRs is a good suggestion. Unfortunately, the version tags on the bug tracker are not consistently maintained and updated. Just because there is a PR attached to an issue doesn’t mean that it would be applicable today to all the versions selected in the issue.
A more accurate approach is to look at open PRs that are either explicitly targeted for 3.7 or which have the “needs backport to 3.7” label. By those metrics, we currently have no open 3.7-specific PRs (the last was merged yesterday) and there are 60 open PRs with the 3.7 backport label. But even that number is high because some of those will end up not getting merged to master at all, and thus not backported, and others will be merged to master for 3.10 and perhaps to 3.9 but deemed inappropriate to backport to 3.8 and/or 3.7.
I would doubt the quality of tags maintenance at Github, too. E.g. https://github.com/python/cpython/pull/12131 is labeled 3.7 and 3.8 at BPO but has no backport tags whatsoever at GH. So the search you gave is clearly insufficient.
https://github.com/python/cpython/pulls?utf8=✓&q=is%3Apr+is%3Aopen+base%3A3.7
-- Ned Deily nad@python.org -- [] -- Regards, Ivan
On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
I would doubt the quality of tags maintenance at Github, too. E.g. https://github.com/python/cpython/pull/12131 <https://github.com/python/cpython/pull/12131> is labeled 3.7 and 3.8 at BPO but has no backport tags whatsoever at GH. So the search you gave is clearly insufficient.
Tags maintenance isn't about quality but rather about automation. Things without backport tags won't get backported unless somebody does it by hand. And even automatically created backports need to be created off of committed pull requests and need to pass tests to be mergeable. Given the limited time until the Monday cutoff, I'd say that almost all of your 700+ BPO open issues that list 3.7 as affected will miss the boat on the fixes. - Ł
On 13.06.2020 3:49, Łukasz Langa wrote:
On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev <python-dev@python.org <mailto:python-dev@python.org>> wrote:
I would doubt the quality of tags maintenance at Github, too. E.g.https://github.com/python/cpython/pull/12131is labeled 3.7 and 3.8 at BPO but has no backport tags whatsoever at GH. So the search you gave is clearly insufficient.
Tags maintenance isn't about quality but rather about automation. Things without backport tags won't get backported unless somebody does it by hand. And even automatically created backports need to be created off of committed pull requests and need to pass tests to be mergeable. Given the limited time until the Monday cutoff, I'd say that almost all of your 700+ BPO open issues that list 3.7 as affected will miss the boat on the fixes.
Except they are not "mine" but everyone's. I'll have some downtime next week so I could look into adding stuff to automatically update labels on existing issues and PRs upon release of a new major version to, say, bedevere. The lack of this is the reason for the discrepancy.
- Ł -- Regards, Ivan
On 6/12/2020 9:31 PM, Ivan Pozdeev via Python-Dev wrote:
On 13.06.2020 3:49, Łukasz Langa wrote:
On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev <python-dev@python.org <mailto:python-dev@python.org>> wrote:
I would doubt the quality of tags maintenance at Github, too. E.g.https://github.com/python/cpython/pull/12131is labeled 3.7 and 3.8 at BPO but has no backport tags whatsoever at GH. So the search you gave is clearly insufficient.
What matters for GH PRs are the backport tags when merged or added thereafter. The problem when adding them when the PR is created is that they may become obsolete. A newer tag may be missing an old tag may become wrong.
Tags maintenance isn't about quality but rather about automation. Things without backport tags won't get backported unless somebody does it by hand. And even automatically created backports need to be created off of committed pull requests and need to pass tests to be mergeable. Given the limited time until the Monday cutoff, I'd say that almost all of your 700+ BPO open issues that list 3.7 as affected will miss the boat on the fixes.
Except they are not "mine" but everyone's.
It is the responsibility of core devs, not release managers, to get patches merged when possible. Release managers can help with reminders and occasional nagging for really important things.
I'll have some downtime next week so I could look into adding stuff to automatically update labels on existing issues and PRs upon release of a new major version to, say, bedevere. The lack of this is the reason for the discrepancy.
There are two things that should and could be done with PRs. 1 (very important - should). When master is bumped from x.y to x.(y+1) and a [Backport to x.y] label is added (currrently at x.y.0b1), add the new label to all PRs *with* [Backport to x.(y-1)]. The latter marks it as a bugfix. Accidentally leaving a bugfix backported to x.(y-1) out of x.y is definitely bad. 2 (less important - could). When x.y is retired to security status, remove [Backport to x.y] *unless* it already has [Backport to x.(y-1)]. The latter marks it as a security issue. I call this less important because, I believe, the label will not be honored unless the merger is the corresponding release manager. I am a bit less enthusiastic about auto-updating bpo 'versions'. When I read New's reminder, I reviewed the 11 remaining open issues tagged 3.5 and closed 5 while tagging the other 6 for 3.10 (which won't immediately become obsolete). I have so far closed nearly 15 of 60 of the remaining issues tagged 3.6. I might not have done the same if they had been auto updated, though looking at the least recently touched issues would have done about as well. All this said, I would like to reconsider *routine* use of version tags. Perhaps 99% of PRs are applied to either master only or master + maintenance, as least if convenient. On the tracker, 'enhancement' means 'apply only to master', not any specific x.y. Similarly, 'behavior' means 'apply to master and backport (if possible or convenient)', not any specific list of versions. The version list is usually redundant and subject to obsolescence. Also, setting version markers should be restricted to triagers and coredevs. -- Terry Jan Reedy
On Jun 12, 2020, at 21:31, Ivan Pozdeev <vano@mail.mipt.ru> wrote:
On 13.06.2020 3:49, Łukasz Langa wrote:
On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev <python-dev@python.org> wrote:
I would doubt the quality of tags maintenance at Github, too. E.g. https://github.com/python/cpython/pull/12131 is labeled 3.7 and 3.8 at BPO but has no backport tags whatsoever at GH. So the search you gave is clearly insufficient. Tags maintenance isn't about quality but rather about automation. Things without backport tags won't get backported unless somebody does it by hand. And even automatically created backports need to be created off of committed pull requests and need to pass tests to be mergeable. Given the limited time until the Monday cutoff, I'd say that almost all of your 700+ BPO open issues that list 3.7 as affected will miss the boat on the fixes.
There is another fundamental issue here and that is the ambiguity of the versions field in BPO issues. The versions fields is used for at least two separate purposes: (1) when the issue is opened, the versions field *usually* is used to indicate which versions exhibit the bug behavior; and (2) if the issue is closed with a fix, the versions field then *usually* indicates to which versions the fix was applied. There is no unambiguous way to tell what the current value of the versions field means. As Terry indicates, many of those BPO issues were originally marked with the releases then currently being maintained but, as new feature releases occur and older releases move from their bugfix to security-fix phases, the version tags should be getting updated but really can't be done automatically because of the ambiguity with which the field is being used today. And, in cny case, as an BPO issue is reviewed and PRs for it are produced and reviewed, to what versions a fix should be applied often changes.
Except they are not "mine" but everyone's.
Again, there aren't really 700 open issues against 3.7. For the most past, there are some large number of issues that, if accepted as problems that need to be fixed, would be fixed against the *current* feature release and would be individually evaluated as to which bugfix and security-fix branches, if any, it should be backported. So, in large part, the version information fields in the BPO issues that have are not actively being worked on aren't that significant. Yes, there are exceptions: ones that are clearly Python 2 only, or ones where the submitter has already identified that the problem is limited to a specific version, for example. But those tend to be the exception and, in any case, can't be easily automatically identified.
I'll have some downtime next week so I could look into adding stuff to automatically update labels on existing issues and PRs upon release of a new major version to, say, bedevere. The lack of this is the reason for the discrepancy.
Thanks for the offer but I don't see how we could make use of something automatic right now. It would likely cause more problems than it would solve. The good news is that the long-discussed plan to migrate Python issue tracking from BPO to Github Issues is just recently starting to get under way, with the formation of a planning team and the intention to hire a project manager. I think that will be the opportunity to address these issues in a permanent way. -- Ned Deily nad@python.org -- []
participants (4)
-
Ivan Pozdeev -
Ned Deily -
Terry Reedy -
Łukasz Langa