llvm dev - Nov 2021 - IMPORTANT: LLVM Bugzilla migration

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

On Tue, 23 Nov 2021 at 15:50, Anton Korobeynikov <anton at
korobeynikov.info>
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.
>
> On Tue, Nov 23, 2021 at 7:11 AM Fangrui Song <maskray at google.com>
wrote:
> >
> > 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.
> >
> > >>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-admin at 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?
>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211124/ffdcd820/attachment.html>

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