[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

Sun May 3 03:13:58 PDT 2020

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>