-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider moving VerifyClosure task into the PackageTesting package #7474
Comments
[Async Triage]: Sounds like general work to be done whenever Tasks.Packaging is deprecated. Seems like "Work tracking by/for other teams" epic as AFAIK Package Testing is entirely a runtime feature |
@MattGal would it be possible to exclude issues that are specific to tools that core-eng doesn't own from the async triage? Of course the question stands how to filter them out. |
@ViktorHofer sorry I'm trying to follow some rules :) If you have zenhub, sticking them in that catch-all epic I mentioned would keep them off triage radar. Failing that, I think someone has added the "I think this is triaged" label that might do the same, or finally if neither works, just saying that in the initial writeup will cause ME to do the first thing when I run into your issues. Apologies for the noise, we're just trying to be disciplined about making sure issues aren't ignored for long periods of time, something we've had challenges with in the past. |
I'm super happy that your team prioritizes triaging incoming issues higher than before. Thanks a lot for doing that. In this case it was me who opened the issue but in other cases it will be someone different who doesn't know much about how Arcade triages their issues. Would it help to add a codeowners file or an area-owners file similar to what we have in dotnet/runtime to list the owners of each component? That might help you reason about which tools are owned by which team. |
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes dotnet#7474
As we plan to deprecate the M.D.B.Tasks.Packaging project in the future, moving the tasks into the PackageTesting project. Fixes #7474
The
VerifyClosure
task is implemented in theMicrosoft.DotNet.Build.Tasks.Packaging
project which will be marked as deprecated or deleted later this year. Both dotnet/runtime's package testing system and the Shared Framework SDK depends on the task so it should be considered to be moved intoMicrosoft.DotNet.PackageTesting
. Both consumers could then take a direct dependency on that package instead.cc @Anipik @ericstj @jkoritzinsky
The text was updated successfully, but these errors were encountered: