Project Tooling SIG

[austinlparker]

This proposal creates a new SIG for project tooling, to aid in the maintenance and development of org-wide tools for OpenTelemetry.

[trask]

I'd like to participate (happy to be a sponsor as well)

[svrnm]

Big +1 for this one and happy to participate.

A question on scope: does "tooling" also include package management (pypi, maven, homebrew, crates, npm, ...) and best practices around them? This is currently owned by the individual SIGs, which should remain that way, but there might be some best practices across them as well we would like to look into (how is code published, by whom, using which mechanism, etc.), which also taps into what SIG security is doing.

[austinlparker]

Big +1 for this one and happy to participate.

A question on scope: does "tooling" also include package management (pypi, maven, homebrew, crates, npm, ...) and best practices around them? This is currently owned by the individual SIGs, which should remain that way, but there might be some best practices across them as well we would like to look into (how is code published, by whom, using which mechanism, etc.), which also taps into what SIG security is doing.

I think we would want to look at what's currently being used, see if there's opportunities for de-duplication, and perhaps provide best practices around things like tooling for secret management or permissions -- but yeah, I think SIGs should continue to manage their own stuff for the most part? That said, the more we can provide 'out of the box' for SIGs the better imo.

[trask]

I think we would want to look at what's currently being used, see if there's opportunities for de-duplication, and perhaps provide best practices around things like tooling for secret management or permissions -- but yeah, I think SIGs should continue to manage their own stuff for the most part

👍

related: #1293

[svrnm]

What about "Infrastructure SIG", similar to what k8s has, or is this too big of a scope what you are thinking of?

[danielgblanco]

Is this following the new template?

[svrnm]

but yeah, I think SIGs should continue to manage their own stuff for the most part? That said, the more we can provide 'out of the box' for SIGs the better imo.

Similar to what Docs, Security, End-User are doing this is a "SIG-to-SIG Service" approach, some SIGs might be not interested, but some other things would be happy to be taken off the burden to do package management on their own. For some package managers (like homebrew, linux distros, etc.) a centralized approach might also be helpful.

It might not be the first thing this SIG tackles, but I would like to have it as part of the charter. For my day-to-day job I have looked into some of those already (pypi, homebrew, ansible, crates, ...) and also helped to define some best practices, I am happy to provide this here as well.

[svrnm]

Suggested change

	- Develop new tools as needed.
	- Develop new tools as needed.
	- Project-wide service for release and package management

See my comment, I would like to establish this "as a service", so SIGs might be able to delegate the package management and focus on other demands.

[austinlparker]

Another note/example of a project that would be really swell for this SIG to tackle - an OTLP/JSON validator in the browser to help people figure out why their OTLP may be malformed.