Is there some kind of mapping between the fields we used to have in Bugzilla and the ones we have in GitHub Issues? I was not able to find such information on the web.
Let me provide some context on the problem that I am trying to solve.
I am part of the Compiler Team in Wind River and we have been doing clang defect classification for a while now. We have a tool that used to retrieve defects from Bugzilla and perform some queries to only show the defects we were interested in based on fields like Product, Component, Version, Importance, Status. I’ve been looking over defects in GitHub Issues and I am not able to see equivalent fields there. It looks like we mostly rely on labels in GitHub Issues. Is that right or am I missing something?
Valentin Chirca, Compiler Engineer @ Wind River
I believe that’s completely correct: in GitHub Issues we rely solely on labels.
Some labels were auto-generated during the migration from Bugzilla fields. If you name the specific Bugzilla fields you care about, then Anton might be able to tell you what the equivalents are (or, that there are no equivalents anymore).
It is also possible to post-facto add labels to the GitHub issues. So, you could try saying something like
“It is important to our workflow that GH issues #42, #375, #1872, #2837… be labeled with the ‘frotz-tool’ label.”
and I’m sure someone would be willing to do that for you. Any committer can apply labels super easily (e.g. via a Python script).
As Arthur already said, GitHub operates solely on labels. During the
migration the labels were created from the combination of
Product+Component as these fields were mostly reliable. The complete
set of labels could be found at
https://github.com/llvm/llvm-project/labels and the mapping using the
migration is here:
Note that since the migration new labels were created, so the mapping
is a bit obsolete.
All other relevant fields were migrated into the table which is
located in the first comment of the issue.