Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mapping bpo numbers in what's new does not reference GitHub issues correctly. #91567

Closed
GadgetSteve opened this issue Apr 15, 2022 · 5 comments
Closed
Assignees
Labels
type-bug An unexpected behavior, bug, or error

Comments

@GadgetSteve
Copy link
Contributor

In the document build process the code in Doc/tools/extensions/pyspecific.py maps BPO or # references to bugs.python.org which as been retired and replaced with Issues in https://github.com/python/cpython/issues/ however while the issues that existed at bugs.python.org all have been ported to https://github.com/python/cpython/issues/ the reference numbers are not the same so simply changing the URL does not map to the correct issue - e.g. BPO-45292 was https://bugs.python.org/issue45292 but is now #89455 i.e. 89455 not 45292

Possible approaches include:

  1. Generate a mapping for all of the BPO entries and using that for all historic commits a large file with no other use
  2. Check each issue to get the link from the BPO page to the GH page time consuming and likely to hit rate limits
  3. Come up with a cut off number where all references below it are still mapped to BPO and those after to GH. may work but where items were opened on BPO and are now on GH may be misleading.
  4. Come up with a tag, e.g. gh or PGH as an alternative to BPO and use the new URL for those - relies on all the users remembering to use it
  5. Any references that are bare # without a BPO prefix reference the GitHub issue but map those with the prefix to BPO. Risk that some older issue references also just use # and are incorrectly mapped as a result.
  6. See if there is a simple formula to transform - if all of the issues were transferred contiguously and in order there may be!
  7. Combine 5 with 3 - less likely to hit both issues at once!

Some guidance/discussion on the preferred approach is needed.

@AlexWaygood AlexWaygood added the type-bug An unexpected behavior, bug, or error label Apr 15, 2022
@hugovk
Copy link
Member

hugovk commented Apr 15, 2022

Ping @ezio-melotti

@GadgetSteve
Copy link
Contributor Author

I notice that the developer guide recommends that a gh- prefix be added to all pull requests we could possibly use this to detect as in 4 above, possibly combined with a git off number for any bare # numbers.

@GadgetSteve
Copy link
Contributor Author

Found that I can export from BPO to a .csv file and then parse it to a dictionary (7121 entries) of BPO numbers to GH numbers - the BPO numbers run from 1062 to 1776674 and the GH numbers from 34627 to 91417 to there is significant overlap - but only 41 collisions.
This might provide some possibilities.

@ezio-melotti
Copy link
Member

This should already be fixed in #91454

@ezio-melotti
Copy link
Member

bpo-* links in https://docs.python.org/3/whatsnew/changelog.html#changelog are now working, so this issue can be closed. If I missed anything let me know!

the BPO numbers run from 1062 to 1776674 and the GH numbers from 34627 to 91417 to there is significant overlap - but only 41 collisions.

bugs.python.org supports automatic redirects now, but I was thinking to expose an API to get the GitHub id from a bpo id (or even just the whole mapping) if it's useful. Note that issues with an high ID (>100k) are old issues that have been migrated from SourceForge when we switched to Roundup, and they kept their old ids. See psf/gh-migration#1 for more info.

@ezio-melotti ezio-melotti self-assigned this Apr 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

4 participants