via llvm-dev
2020-May-01 17:06 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div> <div>> Please reply to this proposal with your questions, comments, praise, or concerns.</div> <div> </div> <div>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.).</div> <div> </div> <div>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.</div> <div> </div> <div>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.</div> <div> </div> <div>Best regards</div> <div>H.</div> <div> </div> </div> <div> </div> <div class="signature"> </div></div></body></html>
Wyatt Childers via llvm-dev
2020-May-01 20:40 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
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) 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-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200501/3efec11f/attachment.html>
Tom Stellard via llvm-dev
2020-May-01 20:49 UTC
[llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
On 05/01/2020 10:06 AM, 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. >I've asked the GitHub developers about the consequences of deleting and renaming another repo, so we'll see what they say. The llvm/llvm repo name was rejected during the conversion. llvm-project was the name of the svn repo already so there was some consistency here, and it also avoided having too many redundant llvm's which seemed confusing. -Tom> Best regards > H. > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >
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 >