[llvm-dev] IMPORTANT: LLVM Bugzilla migration

[Anton Korobeynikov via llvm-dev]

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]

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]

https://forms.gle/tNg86K6T7y2YfsBx9

 

More details can be found in https://lists.llvm.org/pipermail/llvm-dev/2021-March/149441.html

 

Thanks

Phoebe (Pengfei)

[David Blaikie via llvm-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]

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]

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]

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]

> - Where will I find the new tool for PRs?

Code reviews are still happening on Phabricator for now.

-- Tobias

[James Henderson via llvm-dev]

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]

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]

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]

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

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]

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]

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

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]

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

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]

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]

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]

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]

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]

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

[Anton Korobeynikov via 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]

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

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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:

https://bugs.llvm.org/show_bug.cgi?id=38777

https://github.com/llvm/test8/issues/38777

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

Cheers,

-Greg

[Anton Korobeynikov via 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]

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

And one more minor one I've just spotted:

https://github.com/llvm/test8/issues/39890

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

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]

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]

The issue was reported to GitHub as well.

[Petr Hosek via 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]

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]

Let me be more precise: github table markdown extension always
requires a table header (so you cannot drop that "empty line"). In
gitlab this empty header just renders as a wide delimiter. And in
github – as an empty row.

[Renato Golin via llvm-dev]

On Mon, 22 Nov 2021 at 21:04, Anton Korobeynikov <an...@korobeynikov.info> wrote:

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

Anton, I have an idea. Github lets you create an issue template, so that when people try to submit a new one, it comes pre-filled with some meta information.

We could fill up a template saying "Please don't create an issue now, as we're migrating the system". It's not fool-proof, but it does reach the right people if they're not following this thread...

--renato 

[Anton Korobeynikov via llvm-dev]

This is what we already did :) See https://reviews.llvm.org/D114406

[Renato Golin via llvm-dev]

On Tue, 23 Nov 2021 at 19:21, Anton Korobeynikov <an...@korobeynikov.info> wrote:

This is what we already did :) See https://reviews.llvm.org/D114406

:D 

[James Henderson via llvm-dev]

Thanks for the preview!

Could we please make all the existing tools components in bugzillas into their own labels, rather than some arbitrary distinction between them (assuming that the tool still exists in LLVM at least)? For instance, the following tools don't have their own label, but really should:

1) llvm-cxxfilt (corresponds to the llvm-c++filt component): should be tools:llvm-cxxfilt.

2) llvm-mca: should be tools:llvm-mca.

(I'm not familiar enough with the other tool components that don't already have a component to make a distinction)

Also, I noticed a few of these tools:*** labels merged tool names, which is fine, since the tools in question are closely related. However, in some cases, the names are both prefixed with "llvm-" (e.g. "tools:llvm-ar/llvm-ranlib") and in others they aren't (e.g. "tools:llvm-objcopy/strip"). Could we please make sure all such instances are standardised to one form or the other (I don't care that much which, but have a slight preference for both having the "llvm-" prefix)?

Thanks,

James

[Anton Korobeynikov via llvm-dev]

Hello James,

> Could we please make all the existing tools components in bugzillas into their own labels, rather than some arbitrary distinction between them (assuming that the tool still exists in LLVM at least)? For instance, the following tools don't have their own label, but really should:
>
> 1) llvm-cxxfilt (corresponds to the llvm-c++filt component): should be tools:llvm-cxxfilt.
> 2) llvm-mca: should be tools:llvm-mca.

We do have the label mapping document that was created and agreed
during one of the roundtables and reviewed further by the community.
The mapping labels were created according to that document.

> Also, I noticed a few of these tools:*** labels merged tool names, which is fine, since the tools in question are closely related. However, in some cases, the names are both prefixed with "llvm-" (e.g. "tools:llvm-ar/llvm-ranlib") and in others they aren't (e.g. "tools:llvm-objcopy/strip"). Could we please make sure all such instances are standardised to one form or the other (I don't care that much which, but have a slight preference for both having the "llvm-" prefix)?

Thanks for the comments. The changes in label names / representation
could be done post-migration as necessary.

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

[James Henderson via llvm-dev]

Okay, but it's quite possible people missed things on their first pass (myself included, since I thought I at least reviewed the document).

Is there a technical reason these can't be added/changed now before migration?

[Anton Korobeynikov via llvm-dev]

I will double check the mapping, surely :)

[bd1976 llvm via llvm-dev]

Thanks for the work on this.

I'm listed as mannequin in this test issue: https://github.com/llvm/test8/issues/48023.

My best guess is that, as I don't log into github regularly, I only joined the llvm organisation after the test issues were created (I can't find out from githib when I joined an organisation AFAICS).

Hopefully, now that I am a member of the llvm organisation the real migration will list me with my user name?

[Anton Korobeynikov via llvm-dev]

Well, you have submitted "Ben Dunbobbin" as a github username in the
survey. Which apparently is not a valid github username.

[bd1976 llvm via llvm-dev]

Ah ha! Thanks. How can I correct this?

[Anton Korobeynikov via llvm-dev]

Just submit the new form

With best regards,

Anton Korobeynikov

24 нояб. 2021 г., в 13:11, bd1976 llvm <bd197...@gmail.com> написал(а):



[Vy Nguyen via llvm-dev]

Hi,

Is it possible to preserve the [sub]component as labels?

For eg., this bug https://bugs.llvm.org/show_bug.cgi?id=51146 was previously under lld-MachO.

Now it is grouped into one lld label : https://github.com/llvm/test8/issues/51146

Thanks!

Vy

[Shoaib Meenai via llvm-dev]

Ah, yeah, this is pretty important for us; we want to be able to filter by and subscribe to LLD Mach-O bugs specifically.

[Fāng-ruì Sòng via llvm-dev]

Yes. For lld's 4 ports, it would be nice to split the labels, e.g.:

lld-COFF: https://github.com/llvm/test8/issues/28566
lld-ELF: https://github.com/llvm/test8/issues/48023
lld-MachO: https://github.com/llvm/test8/issues/51146
lld-wasm: https://github.com/llvm/test8/issues/45457

>
>
>
>
> Thanks!
>
>
>
> Vy

>
> _______________________________________________
> LLVM Developers mailing list
> llvm...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

--
宋方睿

[Fāng-ruì Sòng via llvm-dev]

On Wed, Nov 24, 2021 at 10:14 AM Fāng-ruì Sòng <mas...@google.com> wrote:
>
> On Wed, Nov 24, 2021 at 10:01 AM Shoaib Meenai via llvm-dev
> <llvm...@lists.llvm.org> wrote:
> >
> > Ah, yeah, this is pretty important for us; we want to be able to filter by and subscribe to LLD Mach-O bugs specifically.
> >
> >
> >
> > From: llvm-dev <llvm-dev...@lists.llvm.org> on behalf of Vy Nguyen via llvm-dev <llvm...@lists.llvm.org>
> > Reply-To: Vy Nguyen <vy...@google.com>
> > Date: Wednesday, November 24, 2021 at 8:23 AM
> > To: "llvm...@lists.llvm.org" <llvm...@lists.llvm.org>
> > Subject: Re: [llvm-dev] IMPORTANT: LLVM Bugzilla migration
> >
> >
> >
> >
> > Hi,
> >
> >
> >
> > Is it possible to preserve the [sub]component as labels?
> >
> > For eg., this bug https://bugs.llvm.org/show_bug.cgi?id=51146 was previously under lld-MachO.
> >
> > Now it is grouped into one lld label : https://github.com/llvm/test8/issues/51146
> Yes. For lld's 4 ports, it would be nice to split the labels, e.g.:
>

After reading https://lists.llvm.org/pipermail/llvm-dev/2021-November/153936.html
, make a correction to the label scheme (use : instead of -)

lld:COFF
lld:ELF
lld:MachO
lld:wasm

[Anton Korobeynikov via llvm-dev]

Sure!

--

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

[Anton Korobeynikov via llvm-dev]

FWIW: I added several workarounds to ensure that all filenames are
unique within the single issue. Hopefully this will allow us to
circumvent the github bug.

On Tue, Nov 23, 2021 at 7:29 PM Anton Korobeynikov
<an...@korobeynikov.info> wrote:
>
> 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
>
> On Tue, Nov 23, 2021 at 7:03 PM Jessica Clarke <jrt...@jrtc27.com> wrote:
> >
> > 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
> >

[chuanqi.xcq via llvm-dev]

Sorry if my question is discussed before.

I received a mail which requires me to offer a bugzilla/username mapping and the deadline was Nov 24.

But I was out of work unluckily so I missed that one. So I want to ask if my previous issues would be missing? Or what should I do in this case?

Thanks,

Chuanqi

[Anton Korobeynikov via llvm-dev]

Hello

The email you received (as well as several other email notifications
sent over last 6 months) already contains the relevant answer:

Q: What will happen if I will not provide email - username mapping?
A: All data produced by unidentified users will be anonymized
during the migration, so there will be no way to attribute data to a
particular github username

Hope this helps

> _______________________________________________
> cfe-dev mailing list
> cfe...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

[chuanqi.xcq via llvm-dev]

Got it. My bad to ignore the Q&A. And I thought it is a little bit fast. I recevied it in Nov 23 and the dead line was Nov 24.

Luckily, it might not be big problem for me since my issues are not so many. I think I could subscribe the corresponding issue by hand after the migration.

Thanks,

Chuanqi

------------------------------------------------------------------

From:Anton Korobeynikov <an...@korobeynikov.info>

Send Time:2021年11月26日(星期五) 15:22

To:chuanqi.xcq <yede...@linux.alibaba.com>

Cc:llvm-dev <llvm...@lists.llvm.org>; clang developer list <cfe...@lists.llvm.org>

Subject:Re: [cfe-dev] [llvm-dev] IMPORTANT: LLVM Bugzilla migration

[Anton Korobeynikov via llvm-dev]

Hello

> Got it. My bad to ignore the Q&A. And I thought it is a little bit fast. I recevied it in Nov 23 and the dead line was Nov 24.
> Luckily, it might not be big problem for me since my issues are not so many. I think I could subscribe the corresponding issue by hand after the migration.

The same emails were sent back in April, in July as well as llvm-dev
notifications.

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

[chuanqi.xcq via llvm-dev]

Oh, I've found it. I'm not sure if I filled that time (probably not). I admit it might be my fault.

Thanks,

Chuanqi

------------------------------------------------------------------

From:Anton Korobeynikov <an...@korobeynikov.info>

Send Time:2021年11月26日(星期五) 15:35

To:chuanqi.xcq <yede...@linux.alibaba.com>

Cc:llvm-dev <llvm...@lists.llvm.org>; clang developer list <cfe...@lists.llvm.org>

Subject:Re: [cfe-dev] [llvm-dev] IMPORTANT: LLVM Bugzilla migration

[Anton Korobeynikov via llvm-dev]

Hello

I double checked and the workaround worked. Now attachments are
different (in the final migration)

On Thu, Nov 25, 2021 at 1:26 PM Anton Korobeynikov

[MyDeveloper Day via llvm-dev]

Anton

Until I read LLVM Weekly I didn't realize you had a document stating the progress

Anyway I'm copying it here for completeness:

https://docs.google.com/document/d/11_3rgYuv-QO0g1oO6T0MmkFhacqJg6o24eWFFVNSX_o/edit

Doesn't this link state that a notification WILL be sent out? So is this a big deal? (What's the most amount of email people are going to get (rsmith?), will the notification have a subject line that allows for easy filtering?)

https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository

Can you update the ETA? How much longer do you expect we will be without a bug tracker? What is the plan if you get no response from github?

I appreciate the hard work, but we need a plan on where we go from here.

MyDeveloperday.

[Anton Korobeynikov via llvm-dev]

Hello

> Until I read LLVM Weekly I didn't realize you had a document stating the progress

I'm so sorry that you missed that link that was posted almost
everywhere: on the mailing list, IRC, Discourse and Discord and even
if you open the bugzilla there is a link.

> Doesn't this link state that a notification WILL be sent out? So is this a big deal? (What's the most amount of email people are going to get (rsmith?), will the notification have a subject line that allows for easy filtering?)
> https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository

Indeed the link states so. However, GitHub told us that they are able
to transfer the issues w/o notifications being sent. Final checking
revealed that they were not quite right (and this is yet another bug
on their side) and in some cases notifications are still sent. They
are working on fixing this issue, unfortunately, the delivery of the
fix was delayed with the major GitHub outage that happened recently
that influenced our migration as well.

The notification would be sent for each issue transferred if the user
was assigned or mentioned in the issue. Tom and Hans, for example,
will receive more than 1k emails thanks to their hard work of being
release managers. In a total, migration of more than 50k issues would
issue several hundred thousand of emails and this is not something we
are going to do: this can overload some mail systems, increase bounce
rates and could create lots of spam filter triggering.

> Can you update the ETA? How much longer do you expect we will be without a bug tracker? What is the plan if you get no response from github?

So far we've been told that the transfer ought to happen within the
next 48 hours. As a last resort we will transfer only a portion of the
bugs – the ones that are open. This would reduce the amount of mailing
at least 3x.