Re: Need help with GitHub Issues migration

On Mon, Feb 24, 2025 at 06:38:05PM +0100, Yury V. Zaytsev wrote:
>The point I was trying to make is that I think active organization and
>moderation will lead to a better signal-to-noise ratio, which I think
>is desirable. Conversely, just opening Discussions without doing
>anything to organize them well and actively moderating them will
>potentially lead to another place in the repository where I don't want
>to be at all, but it will be even harder to avoid being right next to
>issues and code.
>
well, yes.
but you seem to be over-thinking this, presumably due to the bad
experience with average gh contribs.
just think of gh discussions as a slightly better organized mailing list
(so basically a forum).
if (social) problems arise, we'll have to deal with them, but i don't
expect this to become a significant problem. and other than that, it
would seem like a (minor) overall win.

notably, one can trivially spin off issues from discussions, and
vice-versa.

>Speaking of which, would you be interested in issue admin privileges
>for starters?
>
yes

>I think you had them on Trac, if I'm not mistaken.
>
still have. :-)

speaking of which, browsing through all tickets i still see around a
dozen double submissions resulting from trac acting up. shall i use my
powers to clear these out?

>> are you sure? it will definitely send a notification for the mention
>> itself, but if the recipient doesn't respond (which would make them a
>> participant and thus a watcher by default), would they keep receiving
>> followups?
>
>That's how I read their documentation, specifically "Had your username @mentioned", but it seems I'm wrong.
>
>https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/about-notifications#default-subscriptions
>
i'd have read this the same way.
so either the docu is plain wrong, or it's really because the repo is
archived.
unfortunately, i haven't paid attention to that detail on "live"
projects, so i can't tell. we'll see soon enough - nothing to be done
about it anyway.

>https://github.com/marketplace/actions/update-issue-body
>
>Not sure if it's worth the effort though.
>
yeah, and it would be ugly.
i was thinking of adding a (hidden) custom field, but the tracker
doesn't support that. gh projects does, but at a glance that doesn't
seem applicable.

>You can just as easily search for "reporter:ossi or author:ossi".
>
yes, that works. it's just kinda ugly, obviously.
interestingly enough, gh doesn't appear to support saved queries. i
guess they expect users to just make bookmarks.

>> i'm not sure i get what you're saying here. that you can't import the
>> issues into the pre-existing repo?
>
>Yes, that's what I mean. The issue numbers in the current repository
>are busted because on GitHub (historically, unlike GitLab) they share
>the same number space with PRs, and the latter can't be disabled. So
>issue numbers up to about 300 are taken. Either I have to discard those
>Trac tickets, or I have to break the numbering. Or I can take an empty
>repository and fill it with Trac stuff, but then the old PRs will not
>be visible there.
>
the number conflict doesn't seem too big of a deal - you could renumber
the gh stuff on top of the import.
in fact, you could put it close to the start, because the trac numbers
have a huge hole at [428-1363] because of the spam wave back then.
of course, the discrepancy between number and date order would be ugly,
but whatever.

>> that would indeed suck a bit, as there were a few worthwhile
>> discussions in a few PRs. it should be possible to export the data,
>> combine it, and then import it, no?
>
>For issues, I guess that's possible, but we don't have issues in the
>old repository. We only have PRs. And the discussions are mostly
>attached to the code. I see no useful way to export and re-import that
>information into the new repository.
>
i don't see why this shouldn't be possible in _some_ way.
however, it would presumably suffer from the same metadata problems that
issues do.

>I would just keep the old one, rename it to "mc-old", and archive it.
>You can always check the PRs there if you really need to.
>
well, yes. certainly also because of the migration effort.
it just pains my perfectionism. :'-D

>>>>> * Attachment uploads via the API are not supported and will be
>>>>> hosted in a separate repository
>>
>> you mean like that? https://github.com/orgs/community/discussions/46951#discussioncomment-6394596
>
>Yes, correct. That is exactly what I did. I think that's acceptable. Here is an example:
>
>https://github.com/MidnightCommander/mc-test-1/issues/4631
>
oh, indeed you already did. i missed that, because while the attachments
are linked in the blurbs in the issue descriptions, the comments about
adding each attachment aren't linked. this seems like something to fix.
i fact, i'd probably leave out the blurbs, but i don't know what is more
"github-like".

>> maybe https://github.com/j178/github-s3 would be an alternative?
>
>But what is the advantage compared to the above solution? I can only
>see disadvantages (loss of control).
>
at first glance it seemed like it might be "more native", but i haven't
looked into it deeply enough to actually tell.

have you considered converting tickets with patch attachments into PRs?
-- 
mc-devel mailing list
mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
https://lists.midnight-commander.org/mailman/listinfo/mc-devel