[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x
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 mailto:[email protected]>> 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 ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/FLHBVCOVNVJXBXFINLHUWDTFQ5YNFI4M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x
On Jun 12, 2020, at 21:31, Ivan Pozdeev wrote: > On 13.06.2020 3:49, Łukasz Langa wrote: >> On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev >> 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 [email protected] -- [] ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/WTMXUKNANEFFNVYWVQ33FNABJABAQOOT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
On Sat, Jun 13, 2020 at 1:36 AM MRAB wrote:
>
> > * Most of them are `PyUnicode_FromUnicode(NULL, 0);`
> >* We may be able to keep PyUnicode_FromUnicode, but raise error when
> > length>0.
> >
> I think it would be strange to keep PyUnicode_FromUnicode but complain
> unless length == 0. If it's going to be removed, then remove it and
> suggest a replacement for that use-case, such as PyUnicode_FromString
> with a NULL argument. (I'm not sure if PyUnicode_FromString will accept
> NULL, but if it currently doesn't, then maybe it should in future be
> treated as being equivalent to PyUnicode_FromString("").)
Of course, there is an API to create an empty string: PyUnicode_New(0, 0);
But since Cython is using `PyUnicode_FromString(NULL, 0)`,
keep it working for some versions will mitigate the breaking change.
Note that we can remove wchar_t cache while keeping it working.
Anyway, this is an idea for mitigation. If all of maintained packages fixes it
before Python 3.11, mitigation is not needed.
Regards,
--
Inada Naoki
___
Python-Dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/3OD7WH2QUPF5NBM2S6R3KXCGBWLQEQOS/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
On Fri, Jun 12, 2020 at 5:32 PM Inada Naoki wrote: > > > My proposal is, schedule the removal on Python 3.11. But we will postpone > the removal if we can not remove its usage until it. > Additionally, raise DeprecationWarning runtime when these APIs are used. -- Inada Naoki ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/3L456JBACI2UBGKAXYNVBOG7RVEREXPC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
> Additionally, raise DeprecationWarning runtime when these APIs are used. So, just to clarify, current usage of these 7 unicode APIs does not emit any warnings and would only start doing so in 3.10? If so, I think we may want to consider giving users until 3.12 until they're removed. Especially with the shortened yearly release cadence, a single version between deprecation warning and removal feels a bit short. Even if they've already been announced as deprecated in whatsnew and the documentation since 3.3, it's very possible for it to have been missed. In this case, it might be okay to remove in 3.11 since they've been deprecated for an exceptionally long period and appear to have a clear transition path. But, 3.12 would be safer for removal, and I don't think it would be much of an additional burden on our end to keep them around for one extra version. Another option might be to proceed with the 3.11 removal, and simply delay it to 3.12 if we receive significant complaints of breakage in 3.11 to give users some extra time to address it. As far as I'm aware, this isn't typically done, but I think it would be more than reasonable in this scenario (assuming the deprecation warnings are just being introduced in 3.10). On Sat, Jun 13, 2020 at 6:46 AM Inada Naoki wrote: > On Fri, Jun 12, 2020 at 5:32 PM Inada Naoki > wrote: > > > > > > My proposal is, schedule the removal on Python 3.11. But we will > postpone > > the removal if we can not remove its usage until it. > > > > Additionally, raise DeprecationWarning runtime when these APIs are used. > > -- > Inada Naoki > ___ > Python-Dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/3L456JBACI2UBGKAXYNVBOG7RVEREXPC/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/DLFT2BVN4BYV2I4KRZW6B2ZSS7ZVLVG5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
2020年6月13日(土) 20:12 Kyle Stanley : > > Additionally, raise DeprecationWarning runtime when these APIs are used. > > So, just to clarify, current usage of these 7 unicode APIs does not emit > any warnings and would only start doing so in 3.10? > They have been deprecated in C already. Compiler emits warning. This additional proposal is adding runtime warning before removal. In this case, it might be okay to remove in 3.11 since they've been > deprecated for an exceptionally long period and appear to have a clear > transition path. But, 3.12 would be safer for removal, and I don't think it > would be much of an additional burden on our end to keep them around for > one extra version. > I am trying to find and remove use of theses APIs in PyPI packages. We will postpone the removal if the migration is slow. But let's set the goal to 3.11 for now. > > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LZ7VFWJCUF3AL4QKCUUOKCCDDX6KEZMY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: When can we remove wchar_t* cache from string?
> They have been deprecated in C already. Compiler emits warning. > This additional proposal is adding runtime warning before removal. Oh, sorry. I misunderstood the previous statement then. In that case, I think scheduling the removal for 3.11 is perfectly reasonable if the compiler warnings have already been in place. +1. On Sat, Jun 13, 2020 at 7:20 AM Inada Naoki wrote: > > > 2020年6月13日(土) 20:12 Kyle Stanley : > >> > Additionally, raise DeprecationWarning runtime when these APIs are used. >> >> So, just to clarify, current usage of these 7 unicode APIs does not emit >> any warnings and would only start doing so in 3.10? >> > > They have been deprecated in C already. Compiler emits warning. > > This additional proposal is adding runtime warning before removal. > > > In this case, it might be okay to remove in 3.11 since they've been >> deprecated for an exceptionally long period and appear to have a clear >> transition path. But, 3.12 would be safer for removal, and I don't think it >> would be much of an additional burden on our end to keep them around for >> one extra version. >> > > I am trying to find and remove use of theses APIs in PyPI packages. > We will postpone the removal if the migration is slow. > But let's set the goal to 3.11 for now. > >> >> ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LMGTX4MWJ3BDV3VGAGQT3VAWBCVI35RD/ Code of Conduct: http://python.org/psf/codeofconduct/
