Re: Need help with GitHub Issues migration

--===============7233112237291851892==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BCCFD3FC-1B68-4A1C-B594-00DA1872BB2C"


--Apple-Mail=_BCCFD3FC-1B68-4A1C-B594-00DA1872BB2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 25. Feb 2025, at 12:57, Oswald Buddenhagen via mc-devel =
<mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org> wrote:
>=20
> 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.
>>=20
> well, yes.
> but you seem to be over-thinking this, presumably due to the bad
> experience with average gh contribs.

Absolutely, the quality of GitHub interactions has been even worse than =
Trac submissions. I blame this on the fact that opening a GitHub issue / =
PR is extremely easy, while the challenge of registering on our broken =
Trac instance to submit a ticket is a CAPTCHA in itself.

> 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.

All right, you convinced me. Let's give it a try. I have set up ticket =
templates and enabled Discussions:

https://github.com/MidnightCommander/mc-test-1/issues/new/choose

This is what it's going to look like. I hope this will keep the amount =
of junk at bay.

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

I have invited you to the organization. I will sort out the permissions =
later. Thank you.

>> I think you had them on Trac, if I'm not mistaken.
>>=20
> still have. :-)
>=20
> 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?

Thanks for the hint, I took care of what I could find.

>>> 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?
>>=20
>> 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.
>>=20
> 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.

It is definitely possible in *some* way, just as you say:

1) Imported PRs will have the same metadata issues.
2) They're just one repository away and won't be decommissioned like =
Trac.

>> 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.
>>=20
> well, yes. certainly also because of the migration effort.
> it just pains my perfectionism. :'-D

If you come up with a brilliant way to port PRs, we can always do it =
later if we decide not to care about PR numbers, which can't be kept =
anyway: it's either Trac or GitHub. I'm not considering importing PRs =
because I don't see a useful way to represent them, but I'm open to =
someone else doing that part.

> 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".

I tried to dodge it because of the internal data structures of the =
import code, but I think I found a way around it.

Before:

https://github.com/MidnightCommander/mc-test-1/issues/3972

After:

https://github.com/MidnightCommander/mc-test-1/issues/4665

Do you think it's better now?

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

God, no!

First, you have to figure out if the problem is even relevant. After =
that, you'll find that most patches won't apply, and you'll need to find =
a suitable base first. After that, you'll discover that most of the =
patches are of lousy quality and need to be rewritten. Finally, you'll =
have to do something about testing, because submitters usually don't =
care.

I don't see a useful automated way to do this, and I don't want to fuse =
a huge project with another one of even more gigantic proportions. I =
think it would be easier and more productive to implement an AGI and =
task it with making Midnight Commander great again...




--Apple-Mail=_BCCFD3FC-1B68-4A1C-B594-00DA1872BB2C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: =
after-white-space;"><br><div><blockquote type=3D"cite"><div>On 25. Feb =
2025, at 12:57, Oswald Buddenhagen via mc-devel =
&lt;mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>On Mon, Feb 24, 2025 at =
06:38:05PM +0100, Yury V. Zaytsev wrote:<br><blockquote type=3D"cite">The =
point I was trying to make is that I think active organization =
and<br>moderation will lead to a better signal-to-noise ratio, which I =
think<br>is desirable. Conversely, just opening Discussions without =
doing<br>anything to organize them well and actively moderating them =
will<br>potentially lead to another place in the repository where I =
don't want<br>to be at all, but it will be even harder to avoid being =
right next to<br>issues and code.<br><br></blockquote>well, yes.<br>but =
you seem to be over-thinking this, presumably due to the =
bad<br>experience with average gh =
contribs.<br></div></div></blockquote><div><br></div><div>Absolutely, =
the quality of GitHub interactions has been even worse than Trac =
submissions. I blame this on the fact that opening a GitHub issue / PR =
is extremely easy, while the challenge of registering on our broken Trac =
instance to submit a ticket is a CAPTCHA in itself.</div><br><blockquote =
type=3D"cite"><div><div>just think of gh discussions as a slightly =
better organized mailing list<br>(so basically a forum).<br>if (social) =
problems arise, we'll have to deal with them, but i don't<br>expect this =
to become a significant problem. and other than that, it<br>would seem =
like a (minor) overall =
win.<br></div></div></blockquote><div><div><br></div><div>All right, you =
convinced me. Let's give it a try. I have set up ticket templates and =
enabled =
Discussions:</div><div><br></div><div>https://github.com/MidnightCommander=
/mc-test-1/issues/new/choose</div><div><br></div><div>This is what it's =
going to look like. I hope this will keep the amount of junk at =
bay.</div><div><br></div></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite">Speaking of which, =
would you be interested in issue admin privileges<br>for =
starters?<br><br></blockquote>yes<br></div></div></blockquote><div><br></d=
iv><div>I have invited you to the organization. I will sort out the =
permissions later. Thank you.</div><br><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite">I think you had them =
on Trac, if I'm not mistaken.<br><br></blockquote>still have. =
:-)<br><br>speaking of which, browsing through all tickets i still see =
around a<br>dozen double submissions resulting from trac acting up. =
shall i use my<br>powers to clear these =
out?<br></div></div></blockquote><br><div>Thanks for the hint, I took =
care of what I could find.</div><br><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"><blockquote =
type=3D"cite">that would indeed suck a bit, as there were a few =
worthwhile<br>discussions in a few PRs. it should be possible to export =
the data,<br>combine it, and then import it, no?<br></blockquote><br>For =
issues, I guess that's possible, but we don't have issues in the<br>old =
repository. We only have PRs. And the discussions are mostly<br>attached =
to the code. I see no useful way to export and re-import =
that<br>information into the new repository.<br><br></blockquote>i don't =
see why this shouldn't be possible in _some_ way.<br>however, it would =
presumably suffer from the same metadata problems that<br>issues =
do.<br></div></div></blockquote><div><br></div><div><div>It is =
definitely possible in *some* way, just as you =
say:</div><div><br></div><div>1) Imported PRs will have the same =
metadata issues.</div><div>2) They're just one repository away and won't =
be decommissioned like Trac.</div></div><br><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite">I would just keep the =
old one, rename it to "mc-old", and archive it.<br>You can always check =
the PRs there if you really need to.<br><br></blockquote>well, yes. =
certainly also because of the migration effort.<br>it just pains my =
perfectionism. :'-D<br></div></div></blockquote><div><br></div><div>If =
you come up with a brilliant way to port PRs, we can always do it later =
if we decide not to care about PR numbers, which can't be kept anyway: =
it's either Trac or GitHub. I'm not considering importing PRs because I =
don't see a useful way to represent them, but I'm open to someone else =
doing that part.</div><br><blockquote type=3D"cite"><div><div>oh, indeed =
you already did. i missed that, because while the attachments<br>are =
linked in the blurbs in the issue descriptions, the comments =
about<br>adding each attachment aren't linked. this seems like something =
to fix.<br>i fact, i'd probably leave out the blurbs, but i don't know =
what is =
more<br>"github-like".<br></div></div></blockquote><div><br></div><div>I =
tried to dodge it because of the internal data structures of the import =
code, but I think I found a way around =
it.</div><div><br></div><div>Before:</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/issues/3972">https:=
//github.com/MidnightCommander/mc-test-1/issues/3972</a></div><div><br></d=
iv><div>After:</div><div><br></div><div><a =
href=3D"https://github.com/MidnightCommander/mc-test-1/issues/4665">https:=
//github.com/MidnightCommander/mc-test-1/issues/4665</a></div><div><br></d=
iv><div>Do you think it's better now?</div><div><br></div><blockquote =
type=3D"cite"><div><div><blockquote type=3D"cite"><blockquote =
type=3D"cite">maybe https://github.com/j178/github-s3 would be an =
alternative?<br></blockquote><br>But what is the advantage compared to =
the above solution? I can only<br>see disadvantages (loss of =
control).<br><br></blockquote>at first glance it seemed like it might be =
"more native", but i haven't<br>looked into it deeply enough to actually =
tell.<br><br>have you considered converting tickets with patch =
attachments into PRs?</div></div></blockquote><br></div><div><div>God, =
no!</div><div><br></div><div>First, you have to figure out if the =
problem is even relevant. After that, you'll find that most patches =
won't apply, and you'll need to find a suitable base first. After that, =
you'll discover that most of the patches are of lousy quality and need =
to be rewritten. Finally, you'll have to do something about testing, =
because submitters usually don't care.</div><div><br></div><div>I don't =
see a useful automated way to do this, and I don't want to fuse a huge =
project with another one of even more gigantic proportions. I think it =
would be easier and more productive to implement an AGI and task it with =
making Midnight Commander great =
again...</div></div><div><br></div><div><br></div><br></body></html>=

--Apple-Mail=_BCCFD3FC-1B68-4A1C-B594-00DA1872BB2C--

--===============7233112237291851892==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
mc-devel mailing list
mc-devel-+hD5IHI5XseWCegYutOAJTiNl0CLU6MPYPYVAmT7z5s@public.gmane.org
https://lists.midnight-commander.org/mailman/listinfo/mc-devel

--===============7233112237291851892==--