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

Fri May 1 14:05:30 PDT 2020

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