<JAA>
https://foss.heptapod.net/pypy/pypy/-/issues/3765 . Since the issue tracker on the latter is entirely disabled now, the original URLs are also all broken now, so this is actually not directly verifiable; I only saw it because I still have the notification emails.
<cfbolz>
JAA: yes, that is unfortunately correct, above a certain issue number one issue got lost, so there is an off-by-one from some point on
<JAA>
cfbolz: Could this be added to the blog post?
<JAA>
Ideally including the number where the error happened.
<cfbolz>
JAA: yes, good idea. and maybe we can re-open the heptapod one in read only mode
<JAA>
That would also be great, yes.
<JAA>
I like bpo's approach of linking to the new location of the issue. I guess it wouldn't be possible in as nice a way as on bpo (with a warning message at the top of the issue page) since it's GitLab. But maybe an automated 'This issue has moved to <link>' comment?
<JAA>
On bpo, the numbers are completely different, but with this off-by-one error, it'd be nice to have here, too.
<cfbolz>
I'm about to travel to a conference. I'll do the documentation of the switchover point on the blogpost
<cfbolz>
the rest will have to wait
<cfbolz>
JAA: would you be up to adding an issue so we don't forget?
<JAA>
Yeah, this isn't urgent. :-)
<JAA>
Sure, on the main repo?
<cfbolz>
please
<cfbolz>
JAA: no, it actually affects the core devs directly too, because we often have bare issue numbers in commit messages
<ztrawhcse>
it's entirely possible to add a nginx/Apache rewrite redirection that takes effect before one connects to heptapod
<ztrawhcse>
with bpo at least all issue numbers use bpo-1234 and gh-1234 so you can tell the difference
<ztrawhcse>
but that takes foresight so...
<cfbolz>
ztrawhcse: we don't control the webserver of heptapod though
<ztrawhcse>
huh, if you're just a consumer of a service someone else runs then yeah :(
<ztrawhcse>
possibly the least damaging option is to somehow recreate all issues with the final issue before the transition excluded instead
<ztrawhcse>
then all issues other than one are correctly numbered
<ztrawhcse>
unfortunately you don't control GitHub either :D
<cfbolz>
none of that is likely to happen
<cfbolz>
we'll just live with it
<ztrawhcse>
possibly you could adopt the gh-XXXX convention and then at least you can tell people to be cautious about "ambiguous numbers"
<cfbolz>
it's already the third vcs and the third issue tracker, some lossiness was there only both of the steps :-(
<cfbolz>
JAA: thx
korvo has joined #pypy
<JAA>
I wish issues and PRs were stored in the repo itself on a separate orphan branch or similar to avoid such lossiness.
<cfbolz>
our huge problem is that we have extremely few devs right now. so every hosted service that is super convenient wins easily on this point
<JAA>
Yeah, in my fantasy world, all platforms would use this issue and PR data from the repo itself on the web interface. So migration would simply mean pushing to another platform.
<cfbolz>
JAA: that sounds excellent (and in practice might run into the "now there are n+1 standards" problem :-P)
<JAA>
Yeah :-/
<JAA>
Fossil does this, but it's a very niche VCS.
<ztrawhcse>
this exists, I've never used it but always wanted to give it a try
<JAA>
Ah yeah
<ztrawhcse>
fossil is more than merely niche, it's niche because anyone who's used lots of VCSes can tell where the flaws are :D
<ztrawhcse>
(notably the sqlite developers aren't on that list)
<korvo>
I enjoyed my trial of Fossil about 8yrs ago. The main issue I had was the inability to rewrite history, which meant that I typically had dirty working trees, which I see as a data-integrity issue. Still, I see the appeal.