Tom Stellard via llvm-dev
2020-May-01 20:52 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote:> I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > > While I haven't performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn't expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests. > > Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues). > > I'm also going to add an additional concern/question I haven't seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I've seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues -- this seems notably undesirable. (The "bait-and-switch" tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported) >Someone else also mentioned this to me off-list. We don't have a good solution for this right now other than asking people to turn off notifications, but we'll continue to look into this. -Tom> Best, > > Wyatt > > On 5/1/20 1:06 PM, via llvm-dev wrote: >> > Please reply to this proposal with your questions, comments, praise, or concerns. >> >> I think it's by and large a good plan, but I'd consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.). >> >> In a previous mail on this thread there was the proposal for a "bait-and-switch" style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project. >> >> I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the "-project" suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while. >> >> Best regards >> H. >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
Wyatt Childers via llvm-dev
2020-May-01 21:05 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Tom, Followed up on this quickly with some friends who recently imported an issue tracker of a few thousand issues. It seems github has an (undocumented? -- I haven't been able to find any documentation) API for this. I'm not sure how it was found, and the script they used is in written in little known scripting language (MethodScript), however, it's reasonably decipherable: https://github.com/LadyCailin/YoutrackToGithubIssues/blob/master/procs.ms#L224 I'm sure reaching out to github, one could get further information; I suppose the important point here, is there does exist a means to import without sending many emails to subscribers. Best, Wyatt On 5/1/20 4:52 PM, Tom Stellard wrote:> On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: >> I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. >> >> While I haven't performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn't expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests. >> >> Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues). >> >> I'm also going to add an additional concern/question I haven't seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I've seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues -- this seems notably undesirable. (The "bait-and-switch" tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported) >> > Someone else also mentioned this to me off-list. We don't have a good solution > for this right now other than asking people to turn off notifications, but > we'll continue to look into this. > > -Tom > >> Best, >> >> Wyatt >> >> On 5/1/20 1:06 PM, via llvm-dev wrote: >>>> Please reply to this proposal with your questions, comments, praise, or concerns. >>> >>> I think it's by and large a good plan, but I'd consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.). >>> >>> In a previous mail on this thread there was the proposal for a "bait-and-switch" style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project. >>> >>> I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the "-project" suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while. >>> >>> Best regards >>> H. >>> >>> >>> >>> >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>
Anton Korobeynikov via llvm-dev
2020-May-03 09:57 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
We are trying to do our best to reach GitHub and asking how the issues should be addressed. Unfortunately, as I already said, they are not very responsive as they used to be during the repo migration. This adds another complication, e.g. whether we have to wait for their response (= indefinitely) or try some workaround. Currently I'm playing with some workarounds here and there to see if we could progress further w/o their help. On Sat, May 2, 2020 at 12:05 AM Wyatt Childers via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Tom, > > Followed up on this quickly with some friends who recently imported an > issue tracker of a few thousand issues. It seems github has an > (undocumented? -- I haven't been able to find any documentation) API for > this. I'm not sure how it was found, and the script they used is in > written in little known scripting language (MethodScript), however, it's > reasonably decipherable: > https://github.com/LadyCailin/YoutrackToGithubIssues/blob/master/procs.ms#L224 > > I'm sure reaching out to github, one could get further information; I > suppose the important point here, is there does exist a means to import > without sending many emails to subscribers. > > Best, > > Wyatt > > On 5/1/20 4:52 PM, Tom Stellard wrote: > > On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: > >> I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > >> > >> While I haven't performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn't expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests. > >> > >> Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues). > >> > >> I'm also going to add an additional concern/question I haven't seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I've seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues -- this seems notably undesirable. (The "bait-and-switch" tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported) > >> > > Someone else also mentioned this to me off-list. We don't have a good solution > > for this right now other than asking people to turn off notifications, but > > we'll continue to look into this. > > > > -Tom > > > >> Best, > >> > >> Wyatt > >> > >> On 5/1/20 1:06 PM, via llvm-dev wrote: > >>>> Please reply to this proposal with your questions, comments, praise, or concerns. > >>> > >>> I think it's by and large a good plan, but I'd consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.). > >>> > >>> In a previous mail on this thread there was the proposal for a "bait-and-switch" style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project. > >>> > >>> I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the "-project" suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while. > >>> > >>> Best regards > >>> H. > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> LLVM Developers mailing list > >>> llvm-dev at lists.llvm.org > >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > >> _______________________________________________ > >> LLVM Developers mailing list > >> llvm-dev at lists.llvm.org > >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >> > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University
Jonas Hahnfeld via llvm-dev
2020-May-03 10:13 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Hi, I think this is the API "documented" (rather: described) here: https://gist.github.com/jonmagic/5282384165e0f86ef105 If yes, also have a look at https://github.com/nijel/sf2gh which is a Python script to migrate from SourceForge to GitHub. Hope this helps, Jonas Am Freitag, den 01.05.2020, 17:05 -0400 schrieb Wyatt Childers via llvm-dev:> Tom, > > Followed up on this quickly with some friends who recently imported an > issue tracker of a few thousand issues. It seems github has an > (undocumented? -- I haven't been able to find any documentation) API for > this. I'm not sure how it was found, and the script they used is in > written in little known scripting language (MethodScript), however, it's > reasonably decipherable: > https://github.com/LadyCailin/YoutrackToGithubIssues/blob/master/procs.ms#L224 > > > I'm sure reaching out to github, one could get further information; I > suppose the important point here, is there does exist a means to import > without sending many emails to subscribers. > > Best, > > Wyatt > > On 5/1/20 4:52 PM, Tom Stellard wrote: > > On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: > > > I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > > > > > > While I haven't performed this particular trick on Github, based on my experience renaming and removing repositories, I wouldn't expect any significant issue to occur here. It certainly seems less problematic to me, than writing into existing issues (if any), and pull requests. > > > > > > Using new issues, in a new repository not only has UI/UX benefits, but also ensures bugs are accurately transferred to a neutral party (presumably a bot account is going to be the creator of these issues). > > > > > > I'm also going to add an additional concern/question I haven't seen mentioned. Has there been any research done, or strategy picked that would prevent those watching the llvm-project repository from getting spammed with thousands of emails/notifications? Perhaps the llvm organization has the ability to stop this, but smaller projects I've seen move to github issues have generally sent dozens-hundreds of emails in the process of importing their issues -- this seems notably undesirable. (The "bait-and-switch" tactic might actually help here as presumably the new repository could be hidden/unwatched until all issues are imported) > > > > > > > Someone else also mentioned this to me off-list. We don't have a good solution > > for this right now other than asking people to turn off notifications, but > > we'll continue to look into this. > > > > -Tom > > > > > Best, > > > > > > Wyatt > > > > > > On 5/1/20 1:06 PM, via llvm-dev wrote: > > > > > Please reply to this proposal with your questions, comments, praise, or concerns. > > > > > > > > > > > > I think it's by and large a good plan, but I'd consider it a largely unnecessary wart to copy issues into existing PRs (OP would always have the wrong user, etc.). > > > > > > > > In a previous mail on this thread there was the proposal for a "bait-and-switch" style approach, which basically branches off from the proposal around step 5, by locking llvm/llvm-project, syncing all branches with llvm-bug-archive, and then deleting llvm-project and renaming the bug archive to llvm-project. > > > > > > > > I understand that there are unknown unknowns about deleting and replacing the repo in place (maybe those could be allayed by some GH people?), but if that remains a show-stopper, then I was wondering if it has been considered that the new repo could simply just be called llvm/llvm? This would be a nice and short name which is not taken, and then llvm/llvm-project could be archived, and people would only have to change their git remote once. I hope such a suggestion is not seen as sacrilege - my understanding of the llvm-history is hazy at best, but AFAICT the "-project" suffix is not necessary anymore, now that all the subprojects have been absorbed in the monorepo for a while. > > > > > > > > Best regards > > > > H. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > LLVM Developers mailing list > > > > llvm-dev at lists.llvm.org > > > > > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > > > _______________________________________________ > > > LLVM Developers mailing list > > > llvm-dev at lists.llvm.org > > > > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200503/99ffe070/attachment.sig>