Azure / azure-sdk-tools

Tools repository leveraged by the Azure SDK team.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

(PM task) Determine how many existing services have handwritten or generated SDKs + convenience layer

ladonnaq opened this issue · comments

Identify the number of services that are either blocked or not fully supported by the Release Planner App. The data will help us to determine the priority in supporting additional release scenarios or improving existing release scenarios.
 
@ronniegeraghty - Is there a list or way to identify services that have handwritten or generated SDKs + convenience layer?

@ladonnaq could you share why the services that have convenience layer? are blocked using the Release Planner?

I don't believe there is currently a programmatic way to identify what libraries are fully generated vs generated w/ convince layer vs fully hand crafted. Unless the language generators leave some form of watermark on the code they produce that we could pick up on to identify them as generated and/or something similar for convince/hand crafted code.

In a more manual effort, I could start requiring teams that come to the Arch Board to have a linked Release plan. That would send a lot of teams your way with questions on if they can use the release planner with their scenario.

@ladonnaq could you share why the services that have convenience layer? are blocked using the Release Planner?

"Identify the number of services that are either blocked or not fully supported by the Release Planner App." We need to improve the release plans for this scenario by adding documentation to explain how the SDK PR review process. Ronnie is going to discuss with Krzysztof and the arch board. There is no consolidated process documented as far as we know. GitHub issue for docs - #8178.

I don't believe there is currently a programmatic way to identify what libraries are fully generated vs generated w/ convince layer vs fully hand crafted. Unless the language generators leave some form of watermark on the code they produce that we could pick up on to identify them as generated and/or something similar for convince/hand crafted code.

In a more manual effort, I could start requiring teams that come to the Arch Board to have a linked Release plan. That would send a lot of teams your way with questions on if they can use the release planner with their scenario.

@maririos has updated the scheduling tool to include a field for the release plan. Maybe we need to add a question to the "Create a release plan" UI to allow users to identify if they have an existing generated SDK with a convenience layer.
image

@ladonnaq

by adding documentation to explain how the SDK PR review process

This applies to everyone, not just convenience layers. Basically how it works today is we tell them "hey go and read each repo documentation to figure out what you need to do to get your data plane SDK ready and then go to an archboard". This has nothing to do with convenience layers.
So why are we focusing on that?