There is a growing number of issues and PRs in both coreclr and corefx repos which are result of ongoing work in implementation of Intel and Arm hardware instrinsics. It would be very helpful in managing the information flow if that area would have it's own labels to better organize work and information flow.
cc: @karelz @jkotas @tannergooding @CarolEidt @fiigii @sdmaclea
It should probably be area-System.Runtime.Intrinsics, to better match the existing area paths.
Much better than mine - changing title
In general, I am not keen on creating new labels for areas with less than 10-20 issues in CoreFX. I didn't see more than 3-ish issues in CoreFX so far I think. Did I miss more?
BTW: I can't speak on behalf of CoreCLR repo - I assume the JIT work will be tracked under JIT label anyway. The area-System.* namespaces are only for BCL pat of CoreCLR repos.
IMO labels should be our servant, if they are useful for a period, then we should have one, and delete it later.
If it would confuse the area-owner system, it could be a separate label like "Numerics"
IMO labels should be our servant,
Agreed. I just don't think that creating a label for 3-5 issues is doing us any good service. It is creating more clutter IMO and doing us disservice.
As I said, if there's more, I'm on board.
if they are useful for a period, then we should have one, and delete it later.
I think this is independent and more applicable to other non-area labels. That said, I don't believe we do that in practice. We tend to hang on the some-time-ago-useful labels and it is pretty hard to get rid of them :(
label for 3-5 issues
There is more than that - found these without looking too hard. The full list is hard to find because of we do not have a uniform way to mark these.
https://github.com/dotnet/corefx/issues/25933
https://github.com/dotnet/corefx/issues/25926
https://github.com/dotnet/corefx/issues/23519
https://github.com/dotnet/corefx/issues/25386
https://github.com/dotnet/corefx/issues/24346
https://github.com/dotnet/corefx/issues/22940
https://github.com/dotnet/corefx/issues/22843
At minimum, we should have a rule about which corefx area System.Runtime.Intrinsics namespace belongs to and document it in https://github.com/dotnet/corefx/blob/master/Documentation/project-docs/issue-guide.md#areas . Whether it has own label or whether it is folded into existing label is not that important in CoreFX.
In CoreCLR, I agree that we should have a label that we will use to tag the issues related to the hardware intrinsics. There is a lot of them in CoreCLR.
I also imagine many more will open up as the intrinsic are implemented.
Not to mention that Arm is likely going to be in the same boat (pending api review sometime next year).
In CoreCLR, I agree that we should have a label that we will use to tag the issues related to the hardware intrinsics. There is a lot of them in CoreCLR.
Agree with @jkotas, most of the intrinsic work is (and will be) in CoreCLR.
The number of issues grew to 10, so I created the label: https://github.com/dotnet/corefx/issues?utf8=%E2%9C%93&q=is%3Aopen+is%3Aissue+label%3Aarea-System.Runtime.Intrinsics+