Openj9: Creating separate architecture labels for PR/issue classification

Created on 21 Jun 2019  路  9Comments  路  Source: eclipse/openj9

Committers,

I would like to propose separating the architecture from the JIT component labels. That is, having just a comp:jit label and introducing a series of architecture labels:

arch:aarch32
arch:aarch64
arch:power
arch:riscv
arch:x86
arch:z

GitHub doesn't allow you to do a regex search on labels, so when someone wants to find all PRs/issues relating to the comp:jit they have to specify each comp:jit:<arch> label.

Having a separate architecture label will also allow it to be applied to other components as well.

Any objections to this?

If there's interest, we could also create OS and bitness labels as well like OMR does for further classification. For example.

os:aix
os:linux
os:macos
os:windows
os:zos

bits:32
bits:64

Most helpful comment

I created the following labels:

arch:aarch32
arch:aarch64
arch:power
arch:riscv
arch:x86
arch:z

os:aix
os:linux
os:macos
os:windows
os:zos

bits:32
bits:64

And removed the following:

comp:jit:arm
comp:jit:aarch64
comp:jit:p
comp:jit:x
comp:jit:z

All issues and PRs (open and closed) that used the comp:jit:<arch> style have been converted to the new style (i.e., comp:jit arch:<arch>) Please use this style for future classification of JIT issues and PRs.

@fjeremic @andrewcraik @gita-omr @ymanton @mpirvu @dsouzai @mstoodle @vijaysun-omr @zl-wang @knn-k

All 9 comments

Relevant Slack discussion [1] did not get much traction at the time. Hope we get more visibility now. I'm a huge proponent to this as it makes searching for platform/component much easier. For example #6177 was a z/OS only bug which occurs on Z. There is currently no way for me to filter all issues/PRs related to only z/OS. Best I can do is filter to comp:jit && comp:jit:z and manually start looking through each.

[1] https://openj9.slack.com/archives/C8PQL5N65/p1554737411007100

I have no objections. However, the only other comp:jit:* that'll remain after this would be comp:jit:aot. Do you think it's better to leave that as is (in order to open up the possibility of something like comp:jit:<feature>) or rename the AOT tag?

I have no objections. However, the only other comp:jit:* that'll remain after this would be comp:jit:aot. Do you think it's better to leave that as is (in order to open up the possibility of something like comp:jit:<feature>) or rename the AOT tag?

Or just comp:aot?

I'm actually fine with comp:jit:aot as long as there is also a comp:jit label used as well. Even if you had a separate label for comp:aot you probably should use a comp:jit as well to make it easier to query for JIT features. Calling it comp:jit:aot at least provides some attribution of the AOT feature to the JIT component (as opposed to some other top-level component). I'm not sure what really works best, so I'm pretty easy going on this point for now.

In the absence of any dissenting opinions, I will create the independent architecture labels and remove them from the JIT component label, and then fix up past issues/PRs. I will also create OS and bitness tags as well. Thanks for your input. I'll close when this is done.

I created the following labels:

arch:aarch32
arch:aarch64
arch:power
arch:riscv
arch:x86
arch:z

os:aix
os:linux
os:macos
os:windows
os:zos

bits:32
bits:64

And removed the following:

comp:jit:arm
comp:jit:aarch64
comp:jit:p
comp:jit:x
comp:jit:z

All issues and PRs (open and closed) that used the comp:jit:<arch> style have been converted to the new style (i.e., comp:jit arch:<arch>) Please use this style for future classification of JIT issues and PRs.

@fjeremic @andrewcraik @gita-omr @ymanton @mpirvu @dsouzai @mstoodle @vijaysun-omr @zl-wang @knn-k

Thanks @0xdaryl. I think this is a big improvement and generally useful across all components / issues

@mpirvu now that JITServer is a thing shall we deprecate jitaas and rename to comp:jitserver to stay consistent?

yeah, comp:jitserver sounds like a a good idea

Was this page helpful?
0 / 5 - 0 ratings