Issue (re)numbering about gh-migration

[gvanrossum]

So old issues will be in an different repo. But will we be able to create new issues in the cpython repo? (I hope so, so at least for new issues things look “normal”.)

[ezio-melotti]

Ideally it would be better to have all issues -- both old and new -- in the same place. If it's not possible to have them in the python/cpython repo, it might be better to have them all in a separate repo (e.g. python/cpython-issues). I'm investigating with GitHub what will be the consequences of having issues and PRs in two separate repos, and I already thought about a few potential problems/solutions:

• Issue/PR references default to the current repo, so we will either need to specify the correct repo explicitly (e.g. python/cpython#1) or use different prefixes (e.g. GH- for issues and PR- for PRs) and bots/action to fix the URL to point to the correct repo.
• It is possible to create a link in the issue tab that points to the correct repo (e.g. what the vuejs repo does), but redirecting automatically to the right repo when the user clicks on the "Issues" tab will save a click and make the experience more seamless. I don't know yet if there is a way to do it.
• The issue repo will also have to link back to the PR repo, ideally directly from the "Pull requests" tab.
• If we are going to use projects/milestones, we might need to track both PRs and issues, and having them in two different repos might create other problems.

It might also be possible to merge the two repos down the line, so I'm also investigating if this is a realistic possibility and if there is anything we can do to make this easier/possible in the future.

FTR I looked at the last 50 issues on bpo sorted for activity: more than 1/3 have been created over 1 year ago, and more than 1/5 are over 3 years old. If we keep old issues in a separate repo we will have to do back and forth for a long time.

[auvipy]

isn't it possible to transfer the issues from one github repo to another later?

[ezio-melotti]

It should be possible, and in fact we are planning to import to an empty test repo first, and then transfer the issues to the python/cpython repo (it is not possible to import into an existing repo). I still have to do some testing to verify this and make sure we can preserve the issue ID while transferring issues.

[ezio-melotti]

FTR I just verified that after an import, creating a new issue starts from max(issue_ids) + 1. We probably want to renumber the old SF issues so that we don't end up with 7-digits issue ids.

[auvipy]

make sense

[ezio-melotti]

The transfer tool doesn't support preserving issue IDs and will just assign IDs incrementally starting from the highest PR id plus one. In theory we could still try to create a fake issue with e.g. ID 99999 so that the first imported issue will have ID 100000 and a fixed offset, but this is very error prone and probably not worth it.

If possible, it would be better to at least preserve the assumption that the ID order matches the creation order.

[ezio-melotti]

The issues will be migrated by creation date, and will take the first available ID.

This means that:

• 1 to ~32k are the exiting PRs
• ~32k to ~45k will be the old SF issues
• ~45k to ~86k will be the bpo issues
• ~86k+ will be new issues/PRs

There will also be links from the GitHub issues to the bpo issues and vice versa.

---

I also checked if the issue IDs matched the creation date and found a few exceptions among the old SF issues were an issue with lower ID has a more recent creation date than one with a higher ID:
222588 2000-11-16.14:15:39
222589 2000-11-16.14:11:41

233790 2001-02-23.18:02:27
400503 2000-06-06.02:40:44

404275 2001-02-26.13:10:42
404276 2001-02-26.13:10:25

406292 2001-03-06.13:46:02
406293 2001-03-06.13:45:37

406295 2001-03-06.13:46:17
406296 2001-03-06.13:45:52

406297 2001-03-06.13:46:25
406298 2001-03-06.13:46:15

406298 2001-03-06.13:46:15
406299 2001-03-06.13:46:07

406301 2001-03-06.13:46:57
406302 2001-03-06.13:46:50

406304 2001-03-06.13:48:34
406305 2001-03-06.13:48:13

406311 2001-03-06.13:49:20
406312 2001-03-06.13:48:55

406318 2001-03-06.13:56:07
406319 2001-03-06.13:56:00

406321 2001-03-06.13:56:47
406322 2001-03-06.13:56:28

406324 2001-03-06.13:57:10
406325 2001-03-06.13:57:03

431772 2001-06-10.07:55:33
431848 2001-06-09.03:52:00

432208 2001-06-11.21:24:15
432247 2001-06-10.11:06:31

There were also 6 more pairs that were created at the same time and had the same creation date:
494620 2001-12-18.15:32:58
494622 2001-12-18.15:32:58

515026 2002-02-08.22:22:16
515027 2002-02-08.22:22:16

2710 2008-04-28.19:44:50
2711 2008-04-28.19:44:50

2758 2008-05-04.17:42:06
2759 2008-05-04.17:42:06

5632 2009-03-31.21:01:37
5633 2009-03-31.21:01:37

8696 2010-05-12.14:27:09
8697 2010-05-12.14:27:09

[auvipy]

that is great