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

Tom Stellard via llvm-dev
Fri, 01 May 2020 20:52:05 -0000

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