Project Infrastructure SIG #2096
Conversation
austinlparker
requested review from
alolita,
danielgblanco,
dyladan,
jpkrohling,
mtwo,
svrnm,
tedsuo and
trask
as code owners
|
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. |
👍 related: #1293 |
Co-authored-by: Severin Neumann <[email protected]>
danielgblanco
added
the
area/project-proposal
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. |
|
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. |
|
I would love to help out here given the work we began on this issue! Happy to assist in whatever way i can here. |
|
As part of semantic conventions there is already a separate Semantic Convention Tooling SIG (7am Wednesdays), this sounds like the same or at least similar. |
There's a different scope for the two SIGs. |
|
At the very least it seems like what is being proposed is an overall wrapper for what is occurring in that SIG, as we are developing and discussing the "project" tools that every SIG will use for managing not just semantic conventions but also code generation from the semantic conventions. We are also actively looking for additional contributors / maintainers of the project tools being constructed. |
|
Build Tools: https://github.com/open-telemetry/build-tools/tree/main/semantic-conventions |
Sure, I'm sure these two SIGs will coordinate, but there's still a need for project-wide sustaining engineering on things other than semconv code gen. If you would prefer that this SIG subsumes the semconv one, that's a possibility, but I feel like it'd make more sense for that SIG to work independently so it's not blocking adoption. |
There was a problem hiding this comment.
LGTM.
Would it be in scope of this new SIG to consider tooling in support of docs processing (of any form, including for tech docs, specs, etc), and their publication via websites?
From reading the proposal here, I'm not sure that such docs-related tooling is in scope, but if it is, I'm willing to contribute. If it's not in scope, that's fine, but IMHO, there might be a need for shared resources for docs.
I think it'd be in scope, yes. |
|
What's the status of this one? |
|
Just waiting for approvals afaik? |
Alright, you have one more now :-) |
|
A majority of GC members has approved this SIG proposal 🎉 |
|
#2186 summarizes the next steps |
This proposal creates a new SIG for project tooling, to aid in the maintenance and development of org-wide tools for OpenTelemetry.