[llvm-dev] IMPORTANT: LLVM Bugzilla migration

80 views
Skip to first unread message

Anton Korobeynikov via llvm-dev

unread,
Nov 20, 2021, 5:54:13 AM11/20/21
to llvm-dev, clang developer list, Flang Development List, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
Dear Fellow LLVM'ers,

I'm happy to announce that we were able to find workarounds for the
vast majority of GitHub limitations and our dry import went
successfully.

Therefore, the following migration roadmap is proposed:

1. We will put Bugzilla in read-only mode on Wednesday, November 24
23:59 Pacific Time. This will be the last chance to submit the
bugzilla username => github username mapping.
2. We will download the data from Bugzilla and prepare the final
"migration dump" on Thursday, November 25.
3. We will perform the actual migration on November 26 - November 27
and verify the results
4. If everything will go smoothly, we will open the LLVM GitHub repo
for issues no later than on Monday, November 29. Bugzilla will remain
in read-only mode after the migration.

Please DO NOT submit any issues to LLVM github repo during the
migration as it might interfere with the migration process.

Please let me know if there are any objections to this schedule.

--
With best regards, Anton Korobeynikov
On behalf of the LLVM Foundation,
_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Deep Majumder via llvm-dev

unread,
Nov 20, 2021, 6:58:28 AM11/20/21
to Anton Korobeynikov, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
Hi Anton,
Perhaps I have missed it, but how do I submit the Bugzilla to GitHub username mapping?
Warm regards,
Deep

Wang, Pengfei via llvm-dev

unread,
Nov 20, 2021, 7:57:44 AM11/20/21
to Deep Majumder, Anton Korobeynikov, llvm...@lists.llvm.org, clang developer list, Flang Development List, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com

David Blaikie via llvm-dev

unread,
Nov 20, 2021, 2:41:16 PM11/20/21
to Anton Korobeynikov, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), polly-dev
awesome, really glad to hear! Thanks for all the hard work!

(I guess this was probably answered somewhere else/documented somewhere: But will the llvm.org/PRXXXX links be redirected to the github issues at some point as part of this migration?)

Anton Korobeynikov via llvm-dev

unread,
Nov 21, 2021, 2:32:42 AM11/21/21
to David Blaikie, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), polly-dev
Hi David,

Yes. The PR links will forward to new GitHub issues. The old bugzilla
links will be available via llvm.org/bzXXXX links (these are live now,
btw).

Department of Statistical Modelling, Saint Petersburg State University

Björn Pettersson A via llvm-dev

unread,
Nov 21, 2021, 6:38:40 AM11/21/21
to Anton Korobeynikov, clang developer list, Flang Development List, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com, llvm-dev
While I find important information here about migrating
away from Bugzilla in this thread, I kind of lack information
about what we are migrating to.

I've understood that we are migrating from Bugzilla to some
GitHub supported issue handling, but I have zero experience
with issue handling in GitHub.

Here are some of the questions that popped up:

- Where will I find the new tool for PRs?

- Can I find and look at the result of the dry import already
today to familiarize and learn about it?

- And are there any guidelines specific for the LLVM project
related to how to deal with PRs in GitHub?

- Will it be possible to setup emails notification similar
to Bugzilla (e.g. make sure I'm automatically CC:ed on all
issues that my co-workers are involved in)?

Regards,
Björn

Anton Korobeynikov via llvm-dev

unread,
Nov 21, 2021, 8:29:16 AM11/21/21
to Björn Pettersson A, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
Hello

You could certainly check GitHub docs:
https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues

Department of Statistical Modelling, Saint Petersburg State University

Tobias Hieta via llvm-dev

unread,
Nov 22, 2021, 2:46:21 AM11/22/21
to Björn Pettersson A, llvm-dev, clang developer list
> - Where will I find the new tool for PRs?

Code reviews are still happening on Phabricator for now.

-- Tobias

James Henderson via llvm-dev

unread,
Nov 22, 2021, 4:04:34 AM11/22/21
to Anton Korobeynikov, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
All sounds great to me! I wouldn't be surprised if we need to add some documentation on how to use Github Issues specifically related to LLVM (e.g. what labels to apply etc), although I can't really say what that content may be. I believe our bugzilla documentation is virtually non-existent (I apologise if I'm wrong), so this isn't a blocker though.

James

Anton Korobeynikov via llvm-dev

unread,
Nov 22, 2021, 4:10:03 AM11/22/21
to jh737...@my.bristol.ac.uk, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
Thanks, James.

Yes, certainly any patches to import our current document wrt the
workflows are very well welcomed :)

Department of Statistical Modelling, Saint Petersburg State University

James Y Knight via llvm-dev

unread,
Nov 22, 2021, 12:02:09 PM11/22/21
to Anton Korobeynikov, llvm-dev
Looking at the PDF you posted on the other thread, it appears that users who did not fill out the migration google-sheet have their comments migrated with no author-attribution of any kind (not name, not username, or even "Anonymous LLVM Contributor #123". Is that correct?

Thus, it seems pretty important that at least all of the active contributors have filled out the sheet before the migration -- have they? What % of contributors will be converted with comment attribution? (or maybe better: what percent of comments are by someone who filled out the migration sheet vs anonymous?)

I imagine it'd be pretty easy for folks to forget that they didn't fill out the sheet, since there's no way to verify whether you did or not.


Anton Korobeynikov via llvm-dev

unread,
Nov 22, 2021, 12:43:14 PM11/22/21
to James Y Knight, llvm-dev
> Looking at the PDF you posted on the other thread, it appears that users who did not fill out the migration google-sheet have their comments migrated with no author-attribution of any kind (not name, not username, or even "Anonymous LLVM Contributor #123". Is that correct?
That's correct. All such contributions will be attributed to
"llvmbot". There is no other way we can enter "anonymous" data to
github. However, we do provide the backlink to the original bz issue.
We have to anonymize the data in order to comply with some regulations
and there is no way to save the attribution without the explicit
consent.

> Thus, it seems pretty important that at least all of the active contributors have filled out the sheet before the migration -- have they?

There are more than 1k users with commit access to LLVM repo.
Approximately half of them filled the survey. However, there is no
way we can force the contributor to give consent.

> What % of contributors will be converted with comment attribution? (or maybe better: what percent of comments are by someone who filled out the migration sheet vs anonymous?)

I do not have such information. There are no plans to make such an estimation.

> I imagine it'd be pretty easy for folks to forget that they didn't fill out the sheet, since there's no way to verify whether you did or not.

I emailed all contributors that were active (submitted a single bug /
comment) over the last 5 years but who did not fill the bz survey back
in April (after the deadline for the form expired). So, all of them
were notified. We also notified multiple times over the mailing list.
I think it's enough – everyone who cared about "saving" the
contributions would've filled the form by now. So far there are ~2450
entries there.

--
With best regards, Anton Korobeynikov

Department of Statistical Modelling, Saint Petersburg State University

Renato Golin via llvm-dev

unread,
Nov 22, 2021, 1:19:10 PM11/22/21
to Anton Korobeynikov, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
On Sat, 20 Nov 2021 at 10:54, Anton Korobeynikov via llvm-dev <llvm...@lists.llvm.org> wrote:
Please DO NOT submit any issues to LLVM github repo during the
migration as it might interfere with the migration process.

We occasionally have issues created by people that don't read this list, so it'd be better if we could have a way to disable new issues from GH's own settings.

I haven't found a way on my own repos, but perhaps the migration process can do that as part of the setup / teardown.

--renato 

James Y Knight via llvm-dev

unread,
Nov 22, 2021, 3:30:57 PM11/22/21
to Anton Korobeynikov, llvm-dev
On Mon, Nov 22, 2021 at 12:43 PM Anton Korobeynikov <an...@korobeynikov.info> wrote:
> Looking at the PDF you posted on the other thread, it appears that users who did not fill out the migration google-sheet have their comments migrated with no author-attribution of any kind (not name, not username, or even "Anonymous LLVM Contributor #123". Is that correct?
That's correct. All such contributions will be attributed to
"llvmbot". There is no other way we can enter "anonymous" data to
github. However, we do provide the backlink to the original bz issue.
We have to anonymize the data in order to comply with some regulations
and there is no way to save the attribution without the explicit
consent.

If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?

> Thus, it seems pretty important that at least all of the active contributors have filled out the sheet before the migration -- have they?
There are more than 1k users with commit access to LLVM repo.
Approximately half of them filled the survey.  However, there is no
way we can force the contributor to give consent.

Certainly I wasn't asking to force anyone. Rather, I wish to ensure that the people aren't going to be _surprised and unhappy_ when they realize they were omitted! I'd like to make sure folks are given every opportunity to fix that, before it's too late.

I expect nearly everyone who is actively interacting with LLVM bugzilla wants to be included in the migration mapping. Certainly there's going to be a rare person who actively doesn't want it, and a long tail of people who are no longer active in the community, or not easily contacted, who will be excluded because they're unresponsive. But, if there are many people who are currently active in the community (e.g. active on bugzilla or making commits), and yet have not filled out the survey, I think that indicates that we have a problem with outreach.

And, if such a problem exists, I think we ought to address that problem before migration.

everyone who cared about "saving" the contributions would've filled the form by now. 

I very much doubt it's true that everyone who cares will have filled it out already. I mean, just speaking for myself...I think I filled out the form? But maybe I only intended to, but forgot to get around to it? Who knows. Assuming I actually did, I'm certain there are more people in the same situation who actually did _not_.


And on a more general note --

It worries me how little information has been communicated with the community overall for this project, especially now that the migration is supposed to happen imminently! I completely understand how painful it can be to do a migration like this, and how it can feel annoying to have people bugging you about things, yet not actively helping to complete the migration. But...we are going to be stuck with this conversion for a long time, so it is important to validate that people are going to be overall happy with it, right?

Some other questions that pop into my mind:
- Has a full test migration been done now? Or is it impossible to do a full test migration?
- What happens if the migration fails in the middle due to an unforeseen error?
- What sorts of verifications of correctness have been done on the migration output?
- What problematic cases are "known issues" which have been deemed unimportant and therefore ignored?
- How are comments migrated? (e.g. it would appear that some effort was put into ensuring that english prose gets migrated as variable-width text, and code sections get migrated as fixed-width text?)
- How is all the other data migrated? _Is_ all of it migrated? Or are certain fields deemed useless, so we don't migrate them?
- Can we let additional people have access to a test migration, to verify that it seems reasonable? Even if it can't be made public, can the migration can be done to a private repository which can be opened to other llvm community members? (A couple PDFs is certainly better than nothing, but...) What's preventing the ability to do that?
- Is there code that implements this migration that folks can look at and/or suggest changes to?

Or, really, more fundamentally -- where's the document describing the plan? I think that's the root of the issue -- there should be a plan written up, not just one-off answers to those questions that popped up in my mind I listed above, but a document fully describing the final plan for this migration, and why each choice made there is thought to be the best option (or, at least, best practical option, if not actually the best).

I note that people posted suggestions on the previous thread which were dismissed as outdated and unhelpful -- but that's because nobody else has been told any of the information about what tradeoffs have already been considered and dismissed, and what the actual problems are/were. Having a written plan would also help ensure people aren't going to give unhelpful redundant suggestions...


Anton Korobeynikov via llvm-dev

unread,
Nov 22, 2021, 3:36:32 PM11/22/21
to James Y Knight, llvm-dev
> If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
We do this for issues. They are marked as submitted by "LLVM Bugzilla
Contributor".

> And, if such a problem exists, I think we ought to address that problem before migration.

They had more than half a year to submit a survey and received
multiple notifications. We are not going to delay the migration due to
this.

> I very much doubt it's true that everyone who cares will have filled it out already. I mean, just speaking for myself...I think I filled out the form? But maybe I only intended to, but forgot to get around to it? Who knows. Assuming I actually did, I'm certain there are more people in the same situation who actually did _not_.
Well, you can simply go and submit it once again. We will certainly
take care of dups.

> Some other questions that pop into my mind:

Great! Thanks for the questions. Probably they should have asked 2
years ago. You will be able to check the results by yourself after the
migration.

Anton Korobeynikov via llvm-dev

unread,
Nov 22, 2021, 4:04:11 PM11/22/21
to Renato Golin, llvm-dev, Flang Development List, clang developer list, openmp-dev (openmp-dev@lists.llvm.org), poll...@googlegroups.com
Hi Renato

> We occasionally have issues created by people that don't read this list, so it'd be better if we could have a way to disable new issues from GH's own settings.
> I haven't found a way on my own repos, but perhaps the migration process can do that as part of the setup / teardown.

Well... you'd assume that there is a way of doing this. But apparently
there is no :) There is a single switch to turn issues on and off, so
it is not possible to "hide" issues but still work on them. And at
some stage we will need to enable them in order to do some migration
steps. The only way to "protect" the issues is to limit the access to
the repo, but I doubt we can do this. Nothing bad will happen, frankly
speaking, the result will be a bit inaccurate though.

--
With best regards, Anton Korobeynikov

Department of Statistical Modelling, Saint Petersburg State University

Björn Pettersson A via llvm-dev

unread,
Nov 22, 2021, 5:07:53 PM11/22/21
to Tobias Hieta, Anton Korobeynikov, llvm-dev, clang developer list
> -----Original Message-----
> From: Tobias Hieta <tob...@plexapp.com>
> Sent: den 22 november 2021 08:46
> To: Björn Pettersson A <bjorn.a.p...@ericsson.com>
> Cc: Anton Korobeynikov <an...@korobeynikov.info>; clang developer list
> <cfe...@lists.llvm.org>; llvm-dev <llvm...@lists.llvm.org>
> Subject: Re: [llvm-dev] IMPORTANT: LLVM Bugzilla migration
>
> > - Where will I find the new tool for PRs?
>
> Code reviews are still happening on Phabricator for now.
>
> -- Tobias


Well, the issues in Bugzilla are called PR:s (Problem Reports?). So I was actually asking about where I would file/read problem reports after the migration. I have browsed around looking at https://github.com/llvm/llvm-project but I still can't find any llvm-project "issues" when looking at that page (I'm guessing something suddenly will appear on that page later, but I do not really know since I'm not familiar with github issues).


Maybe I won't be able to get an URL to where I will find bugs in the future until after the migration. That however makes it hard to help out to give any feedback in case I see some troubles with the migration beforehand. Except the feedback that I've already given by saying that I lack information about where to find bug reports at the end of this week.

I'm also a bit curious to know if I automatically still will get notifications for all the issues that I subscribing to (as well as all the people I'm stalking in Bugzilla by using the "User Watching" feature). Or if I would need to configure that myself in github somehow. I think that I'd prefer to setup such subscriptions before the migration takes place to avoid any information loss. But since there are no issues in the llvm-project in github today, I do not really know if that even is possible (or if it automatically will be part of the migration - I actually doubt that it will be handled automatically and therefore I'm even more anxious to find out how to do it).


Btw, I'm sorry if I've totally missed out on this information in all the various discussions that's been ongoing the last couple of years. But I just got this IMPORTANT information about the migration happening this week, and it will take some time to read up on all old mail threads etc to get a summary of what actually is migrated or not and what the final plan looks like.

Regards,
Björn

Anton Korobeynikov via llvm-dev

unread,
Nov 22, 2021, 5:13:30 PM11/22/21
to Björn Pettersson A, llvm-dev, clang developer list
Hello Bjoern,

> Well, the issues in Bugzilla are called PR:s (Problem Reports?). So I was actually asking about where I would file/read problem reports after the migration. I have browsed around looking at https://github.com/llvm/llvm-project but I still can't find any llvm-project "issues" when looking at that page (I'm guessing something suddenly will appear on that page later, but I do not really know since I'm not familiar with github issues).

Right. The issues will be in the standard place. They are disable now
for obvious reasons.

> Maybe I won't be able to get an URL to where I will find bugs in the future until after the migration. That however makes it hard to help out to give any feedback in case I see some troubles with the migration beforehand. Except the feedback that I've already given by saying that I lack

We will certainly update the links in the docs and put the banner on
bugzilla to redirect users. Please rest assured that this information
will not be hidden :)

> I'm also a bit curious to know if I automatically still will get notifications for all the issues that I subscribing to (as well as all the people I'm stalking in Bugzilla by using the "User Watching" feature). Or if I would need to configure that myself in github somehow.

If you were CC'ed on the bugzilla issues, then you will be mentioned
on the issue after the migration, so you should be able to receive the
notifications. Our aim (and this is what we spent enormous amounts of
time over the last 2 years) is to preserve as much information as
possible during the migration and to ensure that the old bz
functionality is somehow modelled via github after the migration
(provided all kinds of limitations github imposes).

--
With best regards, Anton Korobeynikov

Department of Statistical Modelling, Saint Petersburg State University

James Y Knight via llvm-dev

unread,
Nov 22, 2021, 6:45:47 PM11/22/21
to Anton Korobeynikov, llvm-dev
On Mon, Nov 22, 2021 at 3:36 PM Anton Korobeynikov <an...@korobeynikov.info> wrote:
> If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
We do this for issues. They are marked as submitted by "LLVM Bugzilla
Contributor". 

As I said, the purpose would be to allow disambiguating multiple anonymous contributors, e.g. by suffixing a unique number to each anonymous contributor. The reply misses that point.

> And, if such a problem exists, I think we ought to address that problem before migration.
They had more than half a year to submit a survey and received
multiple notifications. We are not going to delay the migration due to
this.

My understanding from what you said is that you have sent a single notification to each user back in April. (Plus a mailing list post, before that, in March.) If that is enough to capture most active users, great! But it sounds like it was not. You can't blame the users if a large percentage of them have a problem. That points to a problem in the process, not the people.

> Some other questions that pop into my mind:
Great! Thanks for the questions. Probably they should have asked 2
years ago. You will be able to check the results by yourself after the
migration.

It feels to me like you're being intentionally disingenuous here, and that makes me sad. My questions are about the migration plan/process/decisions as it is now finally implemented, not the initial ideas for migration from 2019. I don't think that a request that the final plan be written down and reviewable by others is out-of-line or unexpected.

Until very recently, it seemed like wasn't even clear that a migration would be feasible under the proposed scheme at all, and that the tooling was still under active development. Now that it's clear that it can be done (which is great news!), the next step I expected was a detailed writeup of the final characteristics of the implementation, and what things are expected to look like afterwards. Instead, at basically the first point where it's known that this is actually feasible, it's too late to ask any questions? There's no documentation of what's been implemented? No description even of what users should expect after migration? I do not understand this.

Certainly it's possible for a project to turn out successfully without a written design, documentation, or review. But isn't that unnecessarily risky?

Fangrui Song via llvm-dev

unread,
Nov 22, 2021, 7:34:12 PM11/22/21
to Anton Korobeynikov, llvm-dev
On 2021-11-22, Anton Korobeynikov via llvm-dev wrote:
>> If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
>We do this for issues. They are marked as submitted by "LLVM Bugzilla
>Contributor".
>
>> And, if such a problem exists, I think we ought to address that problem before migration.
>They had more than half a year to submit a survey and received
>multiple notifications. We are not going to delay the migration due to
>this.
>
>> I very much doubt it's true that everyone who cares will have filled it out already. I mean, just speaking for myself...I think I filled out the form? But maybe I only intended to, but forgot to get around to it? Who knows. Assuming I actually did, I'm certain there are more people in the same situation who actually did _not_.
>Well, you can simply go and submit it once again. We will certainly
>take care of dups.
>
>> Some other questions that pop into my mind:
>Great! Thanks for the questions. Probably they should have asked 2
>years ago. You will be able to check the results by yourself after the
>migration.
>

Thank for all your hard work! This issue tracker system has been a pain
for so many people for years.

I think having a small-scale review of the post-migration github
repository can be very useful. It can be 1% (or larger?) of the current
~53000 issues. People will have some idea what the repository will look
like, e.g. what portion of issues are anonymous.

> James: I imagine it'd be pretty easy for folks to forget that they didn't fill out the sheet, since there's no way to verify whether you did or not."

Agree. Deep Majumder asked the requestion in the thread. A colleague of
mine asked the same question.

I just visited the Bugzilla / GitHub username mapping form and re-submitted my mapping
https://docs.google.com/forms/d/e/1FAIpQLSdUSCK-Rgl9H-8Ua0yat1KL1yELChxkJk15SfhnwPnIexTQUw/viewform
There is no email confirmation.

A contributor may have multiple email addresses. They may not submit
their bugzilla email address or they may miss the notification to their
not-regularly-used email address (possible due to closed registration for
a long time).

Yesterday I read
https://blog.llvm.org/posts/2021-11-18-relicensing-update/ and notified
3 friends who were on the long-tail spreadsheet. Two of them are still
contributing and told me that they missed the email notification because they
had changed their primary email address. I am going to ask them whether
they have submitted the mapping form...


I think bugs.llvm.org has a local patch to display the banner:
"New user self-registration is disabled due to spam. For an account please email bugs-...@lists.llvm.org with your e-mail address and full name."

Could the banner be toggled a bit to remind the user and show the Bugzilla / GitHub usernam mapping if submitted?

Fangrui Song via llvm-dev

unread,
Nov 22, 2021, 11:11:29 PM11/22/21
to Anton Korobeynikov, llvm-dev
On 2021-11-22, Fangrui Song wrote:
>On 2021-11-22, Anton Korobeynikov via llvm-dev wrote:
>>>If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
>>We do this for issues. They are marked as submitted by "LLVM Bugzilla
>>Contributor".
>>
>>>And, if such a problem exists, I think we ought to address that problem before migration.
>>They had more than half a year to submit a survey and received
>>multiple notifications. We are not going to delay the migration due to
>>this.
>>
>>>I very much doubt it's true that everyone who cares will have filled it out already. I mean, just speaking for myself...I think I filled out the form? But maybe I only intended to, but forgot to get around to it? Who knows. Assuming I actually did, I'm certain there are more people in the same situation who actually did _not_.
>>Well, you can simply go and submit it once again. We will certainly
>>take care of dups.
>>
>>>Some other questions that pop into my mind:
>>Great! Thanks for the questions. Probably they should have asked 2
>>years ago. You will be able to check the results by yourself after the
>>migration.
>>
>
>Thank for all your hard work! This issue tracker system has been a pain
>for so many people for years.
>
>I think having a small-scale review of the post-migration github
>repository can be very useful. It can be 1% (or larger?) of the current
>~53000 issues. People will have some idea what the repository will look
>like, e.g. what portion of issues are anonymous.

Extra points that a preview will be useful. We can know:
(use https://bugs.llvm.org/show_bug.cgi?id=42401 as an example)

* How "Status: RESOLVED DUPLICATE of bug 40482" is rendered.
* How "Bug 40482" (there are various forms, e.g. "bug 40482", "PR40482") is rendered. In Bugzilla this translates to https://llvm.org/PR40482
* How Product/Component map to GitHub tags.
* How attachments are rendered. In Bugzilla "Created attachment 22156 [details]" is a hyperlink. I assume that the attachments will just point back to bugs.llvm.org, which will become a static content website in the future.
* How anonymous contributors are suffixed with unique numbers.

Tom Stellard via llvm-dev

unread,
Nov 23, 2021, 12:53:00 AM11/23/21
to James Y Knight, Anton Korobeynikov, llvm-dev
On 11/22/21 15:45, James Y Knight via llvm-dev wrote:

>
>
> On Mon, Nov 22, 2021 at 3:36 PM Anton Korobeynikov <an...@korobeynikov.info <mailto:an...@korobeynikov.info>> wrote:
>
> > If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
> We do this for issues. They are marked as submitted by "LLVM Bugzilla
> Contributor".
>
>
> As I said, the purpose would be to allow disambiguating multiple anonymous contributors, e.g. by suffixing a unique number to each anonymous contributor. The reply misses that point.
>
> > And, if such a problem exists, I think we ought to address that problem before migration.
> They had more than half a year to submit a survey and received
> multiple notifications. We are not going to delay the migration due to
> this.
>
>
> My understanding from what you said is that you have sent a single notification to each user back in April. (Plus a mailing list post, before that, in March.) If that is enough to capture most active users, great! But it sounds like it was not. You can't blame the users if a large percentage of them have a problem. That points to a problem in the process, not the people.
>
> > Some other questions that pop into my mind:
> Great! Thanks for the questions. Probably they should have asked 2
> years ago. You will be able to check the results by yourself after the
> migration.
>
>
> It feels to me like you're being intentionally disingenuous here, and that makes me sad. My questions are about the migration plan/process/decisions /as it is now finally implemented/, not the initial ideas for migration from 2019. I don't think that a request that the final plan be written down and reviewable by others is out-of-line or unexpected.
>


I know it's hard to keep track of all the email threads, but it definitely
would have been more helpful to ask these questions closer
to Oct 11, when Anton outlined the how the migration would work. I
understand the desire to have the best possible data, but at some
point we have to move forward. For many months the migration was
blocked due to lack of communication from GitHub. We finally have
their attention now, and we don't want to lose it again.

We have been discussing this on the Infrastructure Working Group
meetings since August. There has been a lot of time on the list to
ask questions and give feedback. I really think we need to just
move forward.

Anton has already committed his time to do the migration this weekend.
If it doesn't happen then, who is going to volunteer to do it? Anton
doesn't have unlimited free time and has already invested a lot of effort
into the migration.

-Tom

> Until very recently, it seemed like wasn't even clear that a migration would be feasible under the proposed scheme at all, and that the tooling was still under active development. Now that it's clear that it can be done (which is great news!), the next step I expected was a detailed writeup of the final characteristics of the implementation, and what things are expected to look like afterwards. Instead, at basically the first point where it's known that this is actually feasible, it's too late to ask any questions? There's no documentation of what's been implemented? No description even of what users should expect after migration? I do not understand this.
>
> Certainly it's possible for a project to turn out successfully without a written design, documentation, or review. But isn't that unnecessarily risky?
>

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:34:54 AM11/23/21
to Fangrui Song, llvm-dev
> Extra points that a preview will be useful. We can know:
> (use https://bugs.llvm.org/show_bug.cgi?id=42401 as an example)
>
> * How "Status: RESOLVED DUPLICATE of bug 40482" is rendered.
> * How "Bug 40482" (there are various forms, e.g. "bug 40482", "PR40482") is rendered. In Bugzilla this translates to https://llvm.org/PR40482
> * How Product/Component map to GitHub tags.
> * How attachments are rendered. In Bugzilla "Created attachment 22156 [details]" is a hyperlink. I assume that the attachments will just point back to bugs.llvm.org, which will become a static content website in the future.
> * How anonymous contributors are suffixed with unique numbers.
Well. All these things were discussed during our 2019 roundtable and
are migrated into github issues.
Corrupt debug info when using lld with gcc 9.1 · Issue #42401 · llvm_test8.pdf

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:59:08 AM11/23/21
to James Y Knight, llvm-dev
>> > If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
>> We do this for issues. They are marked as submitted by "LLVM Bugzilla
>> Contributor".
> As I said, the purpose would be to allow disambiguating multiple anonymous contributors, e.g. by suffixing a unique number to each anonymous contributor. The reply misses that point.
Thanks for the comment. However, no, it does not. We cannot suffix and
separate different anonymous contributions. I do not want to dig deep
into details, but some regulations require us to ensure that the
author of the data cannot be traced back when the origin of anonymized
data is removed. This requirement is quite vague and quite new, but
still we have to comply with it. One way of doing this is to "pool"
all anonymous contributions so they will be indistinguishable from
each other from the author standpoint.

Mehdi AMINI via llvm-dev

unread,
Nov 23, 2021, 2:31:03 AM11/23/21
to James Y Knight, llvm-dev
+1 with every James said, in particular this last paragraph.

It is amazing that this project finally looks close to completion, but as far as I can tell (and I'm following the iwg@ mailing list as well by the way) there hasn't been a single mockup or test instance that has been shared with the community so that we can have an idea of what does it look like.
There has been very little communication or documentation on this in 2021 as far as I can tell. We just had the LLVM dev meeting last week, this was a perfect opportunity for a demo of the proposed end result and a round table. In comparison, the previous big migrations (SVN to GitHub) went through multiple stages of prototype and demos that were openly shared with the community.

Can we get this demo done and have a proper review of the state of the post-migration? (before any migration happens obviously)

Thanks,


-- 
Mehdi



 

Certainly it's possible for a project to turn out successfully without a written design, documentation, or review. But isn't that unnecessarily risky?

James Henderson via llvm-dev

unread,
Nov 23, 2021, 3:51:29 AM11/23/21
to Mehdi AMINI, llvm-dev
I've got zero issues with the principle of moving to GitHub issues at all. I'm a little concerned by the process here though. Infrastructure projects should be treated just the same as code - it should be open to reviews and consensus driven. Details such as "when" are certainly within the scope of this process, and basically refusing to address concerns that members of the community have asked is no better for infrastructure than it is for a code review.

James

via llvm-dev

unread,
Nov 23, 2021, 9:57:00 AM11/23/21
to jh737...@my.bristol.ac.uk, joke...@gmail.com, llvm...@lists.llvm.org

Is there a link to the list of email-to-github-username mappings?  That would allow people to (a) verify their data was captured, and (b) check for typos.

 

Some of my colleagues really cannot remember whether they filled out the form to associate email addresses with github usernames.  I remember when we did the github migration it was just a file to edit and it was trivial to check.  With no confirmation email sent from the form, and no link to the data, all I can do is say, submit it again just in case.

 

As for myself, I vaguely remember doing it, probably because I had to do it 3 times for different addresses, but it was a *long* time ago.

--paulr

 

From: llvm-dev <llvm-dev...@lists.llvm.org> On Behalf Of James Henderson via llvm-dev
Sent: Tuesday, November 23, 2021 3:51 AM
To: Mehdi AMINI <joke...@gmail.com>
Cc: llvm-dev <llvm...@lists.llvm.org>
Subject: Re: [llvm-dev] IMPORTANT: LLVM Bugzilla migration

 

I've got zero issues with the principle of moving to GitHub issues at all. I'm a little concerned by the process here though. Infrastructure projects should be treated just the same as code - it should be open to reviews and consensus driven. Details such as "when" are certainly within the scope of this process, and basically refusing to address concerns that members of the community have asked is no better for infrastructure than it is for a code review.

 

James

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 10:17:25 AM11/23/21
to paul.r...@sony.com, llvm...@lists.llvm.org
> Is there a link to the list of email-to-github-username mappings? That would allow people to (a) verify their data was captured, and (b) check for typos.
We cannot share such information as it might be considered personal
data in some jurisdictions and could be easily crawled. Everyone who
did not fill out the form received the notification email recently.

Google forms can send emails back only when the "capture emails"
feature is switched on and we heard lots of complaints in the past
about this. Everyone who would like to check it can contact myself.

Thank you for understanding.

--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 10:50:14 AM11/23/21
to Fangrui Song, llvm-dev
Dear All,

After some heavy lifting we were able to make a repo that could be
served as a preview.
https://github.com/llvm/test8 is open for everyone with LLVM commit
access. The example issue in question is
https://github.com/llvm/test8/issues/42401

Please note there is no way we can make it entirely read-only and any
changes might trigger notifications.

--

With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

Renato Golin via llvm-dev

unread,
Nov 23, 2021, 10:58:29 AM11/23/21
to Anton Korobeynikov, llvm-dev
On Tue, 23 Nov 2021 at 15:50, Anton Korobeynikov <an...@korobeynikov.info> wrote:
After some heavy lifting we were able to make a repo that could be
served as a preview.
https://github.com/llvm/test8 is open for everyone with LLVM commit
access. The example issue in question is
https://github.com/llvm/test8/issues/42401

Awesome! This also makes it clear that we still have 17,264 bugs open... :O

Question: the bug description has "Bugzilla Link". Once we migrate, are we going to keep that as a read-only service? If we create a PRXXX service to redirect to Github, then all of those links will be self-redirects...

cheers,
--renato

 

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:00:18 AM11/23/21
to Renato Golin, llvm-dev
Hi Renato,

> Question: the bug description has "Bugzilla Link". Once we migrate, are we going to keep that as a read-only service? If we create a PRXXX service to redirect to Github, then all of those links will be self-redirects...

Slightly less quicker check would reveal that the links are not PR
ones :) We're having https://llvm.org/bzXXXX there.

Tom Stellard via llvm-dev

unread,
Nov 23, 2021, 11:00:37 AM11/23/21
to Renato Golin, Anton Korobeynikov, llvm-dev
On 11/23/21 07:58, Renato Golin via llvm-dev wrote:

> On Tue, 23 Nov 2021 at 15:50, Anton Korobeynikov <an...@korobeynikov.info <mailto:an...@korobeynikov.info>> wrote:
>
> After some heavy lifting we were able to make a repo that could be
> served as a preview.
> https://github.com/llvm/test8 <https://github.com/llvm/test8> is open for everyone with LLVM commit

> access. The example issue in question is
> https://github.com/llvm/test8/issues/42401 <https://github.com/llvm/test8/issues/42401>

>
>
> Awesome! This also makes it clear that we still have 17,264 bugs open... :O
>
> Question: the bug description has "Bugzilla Link". Once we migrate, are we going to keep that as a read-only service? If we create a PRXXX service to redirect to Github, then all of those links will be self-redirects...
>

Yes, bugzilla will be read-only after the migration. Those links are of
the form: https://llvm.org/bz42401 so there will not be self-redirects.

-Tom

> cheers,
> --renato

Jessica Clarke via llvm-dev

unread,
Nov 23, 2021, 11:03:43 AM11/23/21
to Anton Korobeynikov, llvm-dev
Checking through my two open issues, I found a problem with the conversion of one of them, https://github.com/llvm/test8/issues/36461. The original bugzilla bug has two different attachments, one of which was marked obsolete, but both attachments in GitHub link to identical files, which is the obsolete one. So I see three issues with that:

1. Obsolete status is lost (one of the attachments should be shown as obsolete somehow on GitHub)
2. Different attachments are being merged into the same backing file
3. If you are going to abandon obsolete attachments, you *must* not lose the *non-obsolete* ones

This seems like a pretty basic thing that should’ve been caught ages ago; the issue in question has two comments and two attachments, it’s hardly unusual.

Jess

Jessica Clarke via llvm-dev

unread,
Nov 23, 2021, 11:04:07 AM11/23/21
to Anton Korobeynikov, llvm-dev
Checking through my two open issues, I found a problem with the conversion of one of them, https://github.com/llvm/test8/issues/36461. The original bugzilla bug has two different attachments, one of which was marked obsolete, but both attachments in GitHub link to identical files, which is the obsolete one. So I see three issues with that:

1. Obsolete status is lost (one of the attachments should be shown as obsolete somehow on GitHub)
2. Different attachments are being merged into the same backing file
3. If you are going to abandon obsolete attachments, you *must* not lose the *non-obsolete* ones

This seems like a pretty basic thing that should’ve been caught ages ago; the issue in question has two comments and two attachments, it’s hardly unusual.

Jess

James Y Knight via llvm-dev

unread,
Nov 23, 2021, 11:05:52 AM11/23/21
to Anton Korobeynikov, llvm-dev


On Tue, Nov 23, 2021, 1:59 AM Anton Korobeynikov <an...@korobeynikov.info> wrote:
>> > If we can attribute it to an anonymous entity, e.g. by putting "Anonymous LLVM Contributor 123 wrote:" at the top of a comment by llvmbot, at least readers can understand whether two comments on a bug are from the same person or from different people, for example. Can we at least do something like that?
>> We do this for issues. They are marked as submitted by "LLVM Bugzilla
>> Contributor".
> As I said, the purpose would be to allow disambiguating multiple anonymous contributors, e.g. by suffixing a unique number to each anonymous contributor. The reply misses that point.
Thanks for the comment. However, no, it does not. We cannot suffix and
separate different anonymous contributions. I do not want to dig deep
into details, but some regulations require us to ensure that the
author of the data cannot be traced back when the origin of anonymized
data is removed. This requirement is quite vague and quite new, but
still we have to comply with it. One way of doing this is to "pool"
all anonymous contributions so they will be indistinguishable from
each other from the author standpoint.

Thank you for this explanation! That is unfortunate, but it is now perfectly understandable why my suggestion is completely infeasible. (And I'm sorry you have had to become so deeply familiar with these regulations, it sounds quite annoying.)

Is it also disallowed to disambiguate the speakers within a single bug/thread of conversation? (E.g. the first author who posts in a given bug thread is always "1", second is "2" -- not assigning a unique id to a person across the whole migration.) In that way, it's impossible to track an unidentified person across issues, but you still can still follow the flow of the conversation.

It seems "reasonable" that it would be acceptable to de-identify a participant's contributions to a single conversation as a whole, rather than each individual statement separately. However, I don't know anything about what this regulation requires, and regulations are definitely not always reasonable or logical.

Aaron Ballman via llvm-dev

unread,
Nov 23, 2021, 11:23:08 AM11/23/21
to Anton Korobeynikov, llvm-dev
On Tue, Nov 23, 2021 at 10:50 AM Anton Korobeynikov via llvm-dev
<llvm...@lists.llvm.org> wrote:
>
> Dear All,
>
> After some heavy lifting we were able to make a repo that could be
> served as a preview.
> https://github.com/llvm/test8 is open for everyone with LLVM commit
> access. The example issue in question is
> https://github.com/llvm/test8/issues/42401
>
> Please note there is no way we can make it entirely read-only and any
> changes might trigger notifications.

Thank you for this, it's been very useful for spot-checking the
transition. I noticed a few things that I wanted to mention. They may
or may not be issues you can do anything about.

1) GitHub's search is pretty abysmal, but I was not expecting it to be
this level of problematic. Doing a search for something like
"attribute" to see what kind of attribute-related bugs are open is
trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
wasn't expected, but I'm wondering if there's anything to be done
about it?

Bugzilla search:
https://bugs.llvm.org/buglist.cgi?quicksearch=attribute&list_id=227180
GitHub search: https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+attribute

(Note, I get the same useless results in other cases, like
https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+consteval
or https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+concepts)

2) It seems that some user accounts are being created as mannequins
rather than being hooked up to the actual user. For example,
https://github.com/llvm/test8/issues/37237#issuecomment-973565691 is a
comment by zygoloid and it is marked as "mannequin" rather than
linking to https://github.com/zygoloid. Is that expected behavior or
does this indicate some of the data wasn't migrated properly?

Thanks!

~Aaron

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:30:04 AM11/23/21
to Jessica Clarke, llvm-dev
Thanks for the bug report. I double checked all the steps and it looks
like the issue is at the github side. What we provide them is
perfectly fine and a complete dump.

We have two options here:

1. Report the issue to github and wait until the issue is resolved
2. Ignore the issue

Greg Bedwell via llvm-dev

unread,
Nov 23, 2021, 11:36:59 AM11/23/21
to Anton Korobeynikov, llvm-dev
Thanks for sharing this!  It's really helpful (if for nothing else than to see that I obviously did submit the form at some point).

One minor thing I noticed so far (other than keyword search not working at all as Aaron has already pointed out) is that a few of the bug titles have been mangled.  Specifically ones like this:


where the [DebugInfo@O2] tag has been turned into [DebugInfo@&#8203;O2]

Cheers,
-Greg




Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:39:51 AM11/23/21
to Aaron Ballman, llvm-dev
> 1) GitHub's search is pretty abysmal, but I was not expecting it to be
> this level of problematic. Doing a search for something like
> "attribute" to see what kind of attribute-related bugs are open is
> trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
> wasn't expected, but I'm wondering if there's anything to be done
> about it?
We can try to report this issue to github folks and see what could be
done. Maybe it's a matter of some text index to be rebuilt.

> 2) It seems that some user accounts are being created as mannequins
> rather than being hooked up to the actual user. For example,
> https://github.com/llvm/test8/issues/37237#issuecomment-973565691 is a
> comment by zygoloid and it is marked as "mannequin" rather than
> linking to https://github.com/zygoloid. Is that expected behavior or
> does this indicate some of the data wasn't migrated properly?

"mannequins" are those who are not members of LLVM organization (they
will be treated separately after the migration).
It was also a surprise to me that Richard does not have LLVM GH repo
commit access :)

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:41:08 AM11/23/21
to Greg Bedwell, llvm-dev
> where the [DebugInfo@O2] tag has been turned into [DebugInfo@&#8203;O2]
This is a known issue, yes, that is already fixed. We have to sanitize
things like #1 and !1234 that appears a lot in LLVM IR and this
routine was quite aggressive in the past

Greg Bedwell via llvm-dev

unread,
Nov 23, 2021, 11:41:26 AM11/23/21
to Anton Korobeynikov, llvm-dev
And one more minor one I've just spotted:


where this block of code:
# define B4 b; b; b; b
# define B16 B4; B4; B4; B4
# define B64 B16; B16; B16; B16
# define B256 B64; B64; B64; B64
# define B1024 B256; B256; B256; B256
has been interpreted as markup.  Is it possible to automatically escape such characters?

Cheers,
-Greg








Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:46:42 AM11/23/21
to Greg Bedwell, llvm-dev
Not quite. Github uses markdown and LLVM bugzilla is text-only with
some minor formatting. Surprisingly enough there are almost no
possibilities to "escape" the stuff in the GitHub markdown engine. We
decided to keep the text as-is. If necessary one could reformat the
comment during commenting / fixing.

Fraser Cormack via llvm-dev

unread,
Nov 23, 2021, 11:50:19 AM11/23/21
to an...@korobeynikov.info, aa...@aaronballman.com, llvm...@lists.llvm.org
On Tue, 2021-11-23 at 19:39 +0300, Anton Korobeynikov via llvm-dev
wrote:
> > 2) It seems that some user accounts are being created as mannequins
> > rather than being hooked up to the actual user. For example,
> > https://github.com/llvm/test8/issues/37237#issuecomment-973565691
> > is a
> > comment by zygoloid and it is marked as "mannequin" rather than
> > linking to
> > https://github.com/zygoloid
> > . Is that expected behavior or
> > does this indicate some of the data wasn't migrated properly?
>
> "mannequins" are those who are not members of LLVM organization (they
> will be treated separately after the migration).
> It was also a surprise to me that Richard does not have LLVM GH repo
> commit access :)
>

This particular issue seems inconsistent. I happened to come across
https://github.com/llvm/test8/issues/52340 and in the CC there is
@zygoloid, correctly linked to that person's GH account. Why might it
work in some cases but not others?

Cheers,
Fraser

Aaron Ballman via llvm-dev

unread,
Nov 23, 2021, 11:50:36 AM11/23/21
to Anton Korobeynikov, llvm-dev
On Tue, Nov 23, 2021 at 11:39 AM Anton Korobeynikov
<an...@korobeynikov.info> wrote:
>
> > 1) GitHub's search is pretty abysmal, but I was not expecting it to be
> > this level of problematic. Doing a search for something like
> > "attribute" to see what kind of attribute-related bugs are open is
> > trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
> > wasn't expected, but I'm wondering if there's anything to be done
> > about it?
> We can try to report this issue to github folks and see what could be
> done. Maybe it's a matter of some text index to be rebuilt.

Thanks! I'm hopeful that we can find a solution because this is almost
a show-stopper for me. I've spent several weeks going through Bugzilla
to triage C++20-specific issues and as best I can tell, GitHub would
be unable to accomplish this task *at all* (because many bugs were
reported before we had a tag for users to apply and not all bugs are
things that we had bugzilla tags for anyway -- we need a searchable
bug database). So hopefully it's a matter of rebuilding some text
index or something straightforward like that.

> > 2) It seems that some user accounts are being created as mannequins
> > rather than being hooked up to the actual user. For example,
> > https://github.com/llvm/test8/issues/37237#issuecomment-973565691 is a
> > comment by zygoloid and it is marked as "mannequin" rather than
> > linking to https://github.com/zygoloid. Is that expected behavior or
> > does this indicate some of the data wasn't migrated properly?
> "mannequins" are those who are not members of LLVM organization (they
> will be treated separately after the migration).
> It was also a surprise to me that Richard does not have LLVM GH repo
> commit access :)

Oh, interesting. Thanks for the explanation

~Aaron

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 11:52:45 AM11/23/21
to Fraser Cormack, llvm...@lists.llvm.org
> This particular issue seems inconsistent. I happened to come across
> https://github.com/llvm/test8/issues/52340 and in the CC there is
> @zygoloid, correctly linked to that person's GH account. Why might it
> work in some cases but not others?
On GitHub you could mention arbitrary users in the comments. However,
you cannot assign issues to non-members. Again, this is question which
should be asked to GitHub, not to myself.

--
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University

Jessica Clarke via llvm-dev

unread,
Nov 23, 2021, 11:53:09 AM11/23/21
to Anton Korobeynikov, llvm-dev
I would be surprised if one of my two open bugs was the only one with
this issue, so I imagine some serious auditing needs to be done to
determine the scope of the issue. If it’s just a few then presumably
that can be worked around manually, but if it’s more widespread than
that then an alternative strategy is needed.

Jess

Michael Kruse via llvm-dev

unread,
Nov 23, 2021, 12:01:03 PM11/23/21
to Aaron Ballman, llvm-dev
Am Di., 23. Nov. 2021 um 10:23 Uhr schrieb Aaron Ballman via llvm-dev
<llvm...@lists.llvm.org>:

> 1) GitHub's search is pretty abysmal, but I was not expecting it to be
> this level of problematic. Doing a search for something like
> "attribute" to see what kind of attribute-related bugs are open is
> trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
> wasn't expected, but I'm wondering if there's anything to be done
> about it?
>
> Bugzilla search:
> https://bugs.llvm.org/buglist.cgi?quicksearch=attribute&list_id=227180
> GitHub search: https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+attribute
>
> (Note, I get the same useless results in other cases, like
> https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+consteval
> or https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+concepts)

I noticed this too, but it seems that the search is "just" broken: I
could not find a query (other than author:@me, is:open and/or
is:issue) returning any result, even searching for "a" or "the"

Michael

Michael Kruse via llvm-dev

unread,
Nov 23, 2021, 12:04:46 PM11/23/21
to Michael Kruse, llvm-dev
Am Di., 23. Nov. 2021 um 11:00 Uhr schrieb Michael Kruse
<llv...@meinersbur.de>:

> Am Di., 23. Nov. 2021 um 10:23 Uhr schrieb Aaron Ballman via llvm-dev
> <llvm...@lists.llvm.org>:
> > 1) GitHub's search is pretty abysmal, but I was not expecting it to be
> > this level of problematic. Doing a search for something like
> > "attribute" to see what kind of attribute-related bugs are open is
> > trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
> > wasn't expected, but I'm wondering if there's anything to be done
> > about it?
> >
> > Bugzilla search:
> > https://bugs.llvm.org/buglist.cgi?quicksearch=attribute&list_id=227180
> > GitHub search: https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+attribute
> >
> > (Note, I get the same useless results in other cases, like
> > https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+consteval
> > or https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+concepts)
>
> I noticed this too, but it seems that the search is "just" broken: I
> could not find a query (other than author:@me, is:open and/or
> is:issue) returning any result, even searching for "a" or "the"

Seems to be an indexing issue on GitHub's side. A added a comment to
https://github.com/llvm/test8/issues/32534, now it shows up in my
queries, but nothing else.

Tom Stellard via llvm-dev

unread,
Nov 23, 2021, 12:07:43 PM11/23/21
to Michael Kruse, llvm-dev
On 11/23/21 09:03, Michael Kruse via llvm-dev wrote:
> Am Di., 23. Nov. 2021 um 11:00 Uhr schrieb Michael Kruse
> <llv...@meinersbur.de>:
>> Am Di., 23. Nov. 2021 um 10:23 Uhr schrieb Aaron Ballman via llvm-dev
>> <llvm...@lists.llvm.org>:
>>> 1) GitHub's search is pretty abysmal, but I was not expecting it to be
>>> this level of problematic. Doing a search for something like
>>> "attribute" to see what kind of attribute-related bugs are open is
>>> trivial in Bugzilla and utterly useless in GitHub. I'm guessing this
>>> wasn't expected, but I'm wondering if there's anything to be done
>>> about it?
>>>
>>> Bugzilla search:
>>> https://bugs.llvm.org/buglist.cgi?quicksearch=attribute&list_id=227180
>>> GitHub search: https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+attribute
>>>
>>> (Note, I get the same useless results in other cases, like
>>> https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+consteval
>>> or https://github.com/llvm/test8/issues?q=is%3Aissue+is%3Aopen+concepts)
>>
>> I noticed this too, but it seems that the search is "just" broken: I
>> could not find a query (other than author:@me, is:open and/or
>> is:issue) returning any result, even searching for "a" or "the"
>
> Seems to be an indexing issue on GitHub's side. A added a comment to
> https://github.com/llvm/test8/issues/32534, now it shows up in my
> queries, but nothing else.
>

This could be related to the fact that this is a private repo and we
don't have full permissions on it.

-Tom

James Y Knight via llvm-dev

unread,
Nov 23, 2021, 12:25:20 PM11/23/21
to Aaron Ballman, llvm-dev
Richard is making ongoing commits to LLVM Github which are properly attributed to his GH account, though: https://github.com/llvm/llvm-project/commits?author=zygoloid


David Blaikie via llvm-dev

unread,
Nov 23, 2021, 12:32:07 PM11/23/21
to Aaron Ballman, Richard Smith, llvm-dev

It looks like Richard Smith, under zygoloid, does have LLVM GH repo commit access, though? eg: https://github.com/llvm/llvm-project/commits?author=zygoloid

So it seems maybe there are people with commit access but are not part of the "LLVM organization" on github?
 

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 12:43:28 PM11/23/21
to David Blaikie, llvm-dev
Right. It turned out that some of the LLVM committers are added as
"external collaborators" just to the single llvm-project repo. I do
not know why,
but this certainly should be fixed.

Tom Stellard via llvm-dev

unread,
Nov 23, 2021, 12:59:45 PM11/23/21
to Anton Korobeynikov, David Blaikie, llvm-dev
On 11/23/21 09:42, Anton Korobeynikov via llvm-dev wrote:
> Right. It turned out that some of the LLVM committers are added as
> "external collaborators" just to the single llvm-project repo. I do
> not know why,
> but this certainly should be fixed.
>

Some people did not accept the invite to join the LLVM organization when
we switched from "external collaborators" to organization membership for
granting commit access, so they are still listed as "external collaborators".

I just resent all the invites that weren't accepted, so people have a chance
to join the organization again.

-Tom

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:00:24 PM11/23/21
to Jessica Clarke, llvm-dev
This was reported to GitHub. This is the kind of bugs we've introduced
numerous workarounds in the past as they are not fixed on github
end...

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:01:22 PM11/23/21
to Aaron Ballman, llvm-dev
The issue was reported to GitHub as well.

Petr Hosek via llvm-dev

unread,
Nov 23, 2021, 1:26:31 PM11/23/21
to Anton Korobeynikov, llvm-dev
I have noticed that in the generated Markdown table at the top of each issue, there's always an empty first row:

|  |  |
| --- | --- |
| Bugzilla Link | ... |
| Version | ... |
| OS | ... |
| CC | ... |

Is that intentional?

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:30:28 PM11/23/21
to Petr Hosek, llvm-dev
A bit. There are some differences in different markdown flavours how
the table headers are rendered. And this where gitlab (tooling for
which was adopted) and github disagree. This was workaround recently,
but not included into this particular migration instance.

--

Anton Korobeynikov via llvm-dev

unread,
Nov 23, 2021, 1:35:37 PM11/23/21