Now that 7.3.14 has been released, I would like to move the canonical repo for pypy and rpython to github. Reasons: - foss.heptapod.net is not well tracked in google/bing/duckduckgo search, so people find it hard to search for issues in the project - since the site has tightened its spam control, we get reports that users create issues only to have them flagged as spam - open source has become synonymous with github, and we are too small to change that - Much of the current development comes as a reaction to fixing issues. Tracking interlocking issues is easier if all the code is on the same platform - The FAQ [2] presents two arguments against the move. Github notes [3] solves much of point (1), although not entirely. But the main problem is point (2), it turns out that __not__ moving to github is an impediment to contribution and issue reporting. - As development effort winds down, github is a better archive for PyPy than foss.heptapod.net. I cannot predict the future, but if there is a move to revive the project, or to move to another platform, I believe github will provide a better jumping-off point as well. And since the repo at foss.heptapod.net will not be deleted, even if I am wrong I expect the effort to port the issues and commits from github will be manageable. - People who wish to continue to use mercurial can add a cron job github action to pull the changes from foss.heptapod.net across to github - github is more resource rich than foss.heptapod.net. We can add CI jobs to replace some of our aging buildbot infrastructure (still using buildbot 0.8 and python2). Technique: These steps will be done in a private repo - I will convert the repo to git and add a note to most of the commits (where I can) which will allow using "git log --notes=branch" to determine which branch a commit came from. More details at [0] - I will convert the issues and PRs to github via [1]. Using a private repo prevents spamming issue authors with emails about the transfer. Then I will make the repo public: - Move it to github.com/pypy/pypy - Freeze the issue tracker at https://foss.heptapod.net/pypy/pypy/-/issues, and add a message that development has moved - Write a blog post - Modify the links in the documentation - Activate the github action in [3] to add a branch note to each git commit Anything else? Any suggestions to make the transition easier? Matti [0] https://gist.github.com/mattip/b6752c164a075c2aa53f4069e9c30573 [1] https://github.com/piceaTech/node-gitlab-2-github [2] https://doc.pypy.org/en/default/faq.html#why-doesn-t-pypy-use-git-and-move-t... [3] https://github.com/Julian/named-branch-action
Welcome news, if only because of my terrible mercurial skills 😅 I tried with only partial success to get the unit tests working on github runners some time ago (see https://github.com/olliemath/pypy/actions/runs/3851138348 ) Hopefully some of the required work might be useful in the future: https://github.com/mozillazg/pypy/compare/master...olliemath:pypy:master Best, On Thu, 28 Dec 2023 at 14:25, David Edelsohn <dje.gcc@gmail.com> wrote:
On 28/12/23 10:20, Matti Picus wrote:
- I have created the repo at github.com/pypy/pypy. It is still private so only some of you will be able to see it. Please take a look at a few issues and branches and make sure things look OK. - I also wrote a draft blog post as a PR https://github.com/pypy/pypy.org/pull/108, the preview is at https://deploy-preview-108--keen-mestorf-442210.netlify.app/blog/. Please comment on the PR. - I couldn't figure out how to add a message to the heptapod issue tracker, but I did disable issue and PR creation at heptapod. Project developers can still create issues, but not non-project members. I will make this all public before year's end unless someone spots a problem. There is a bit of redundancy in branch names. The git-remote-hg script uses branches/XXX when converting a branch name, but heptapod/gitlab use branch/XXX (without the "es") so the repo has both names for many branches. We will have to decide which one to keep tracking. Matti
On 31/12/23 00:55, Matti Picus wrote:
The repo is live, and the issue tracker is open. The post on https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html has more information. Matti
Welcome news, if only because of my terrible mercurial skills 😅 I tried with only partial success to get the unit tests working on github runners some time ago (see https://github.com/olliemath/pypy/actions/runs/3851138348 ) Hopefully some of the required work might be useful in the future: https://github.com/mozillazg/pypy/compare/master...olliemath:pypy:master Best, On Thu, 28 Dec 2023 at 14:25, David Edelsohn <dje.gcc@gmail.com> wrote:
On 28/12/23 10:20, Matti Picus wrote:
- I have created the repo at github.com/pypy/pypy. It is still private so only some of you will be able to see it. Please take a look at a few issues and branches and make sure things look OK. - I also wrote a draft blog post as a PR https://github.com/pypy/pypy.org/pull/108, the preview is at https://deploy-preview-108--keen-mestorf-442210.netlify.app/blog/. Please comment on the PR. - I couldn't figure out how to add a message to the heptapod issue tracker, but I did disable issue and PR creation at heptapod. Project developers can still create issues, but not non-project members. I will make this all public before year's end unless someone spots a problem. There is a bit of redundancy in branch names. The git-remote-hg script uses branches/XXX when converting a branch name, but heptapod/gitlab use branch/XXX (without the "es") so the repo has both names for many branches. We will have to decide which one to keep tracking. Matti
On 31/12/23 00:55, Matti Picus wrote:
The repo is live, and the issue tracker is open. The post on https://www.pypy.org/posts/2023/12/pypy-moved-to-git-github.html has more information. Matti
participants (7)
-
Armin Rigo -
CF Bolz-Tereick -
David Edelsohn -
Maciej Fijalkowski -
Matti Picus -
Oliver Margetts -
Simon Cross