On Jun 12, 2020, at 21:31, Ivan Pozdeev <v...@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 n...@python.org -- [] _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/WTMXUKNANEFFNVYWVQ33FNABJABAQOOT/ Code of Conduct: http://python.org/psf/codeofconduct/
