Merge pull request WebAssembly#302 from kate-goldenring/sig-docs-05-22

SIG Docs Meeting nots 05-22

SIG-Documentation/2024/docs-05-22.md

@@ -6,17 +6,29 @@
 
 1. Opening, welcome and roll call
 1. Announcements
-    1. _Submit a PR to add your announcement here_
+    1. None
 1. Other agenda items
-    1. _Submit a PR to add your item here_
+    1. Discussion around vendor neutrality in BA docs with regards to registries from this [PR](https://github.com/bytecodealliance/component-docs/pull/129)
 
 ## Attendees
 
-* TODO
+* Ryan Levick
+* Daniel Macovei
+* Eric Gregory
+* Calvin Prewitt
+* Kate Goldenring
 
 ## Notes
 
-* TODO
+* **Discussion around vendor neutrality in BA docs**
+  * Danny was working on documenting the Warg registry integration with `wac` and `cargo-component` in the component docs in  this [PR](https://github.com/bytecodealliance/component-docs/pull/129). Unfortunately, wa.dev is the only active component registry. The BA TSC chimed in on the PR, saying that they want everything related to BA projects needs to be as vendor neutral as possible. The only acceptable vendor neutral option is GHCR, which is an OCI registry. OCI will be an option for tooling. So cannot merge that PR as is.
+  * [`wasm-pkg-tools`](https://github.com/bytecodealliance/wasm-pkg-tools/) with [`wkg`](https://crates.io/crates/wkg) cli will be able to talk to OCI and warg registries. When that happens, we can update this PR. Still should review the PR because the change is going to be minor. A feature that is already live in this tooling, is that you can point it to a domain with a `.well-known` JSON file that provides a URL to where the actual registry is. There is a `.well-known` configured on bytecodealliance.org. All BA projects will point to the `.well-known` there. For now, that points to GHCR. TSC can change what that points to. The [`wkg`](https://crates.io/crates/wkg) tool will give you the option to configure that different namespaces point to different registries. There will probably also be a WIT dependencies replacement built into this. Right now that is a sub-crate of `cargo-component` -- we will have a revised command of that in `wkg`. 
+  * SIG registries group is having discussions on renaming and rescoping the group to be "SIG-packaging" for packaging problems for distributing components. Warg will probably will still be in scope but also OCI and maybe tools for programming language ecosystems to better integrate. 
+  * Timeline: Tooling to enable using the BA GHCR will come together over the next month. Not too far away from working but some more updates needed.
+  * Regarding the currently existing PR, there is also new content unrelated to wa.dev, such as the `wac plug` changes. Danny will open a PR to rip those things out of the current PR. `wac plug` wasn't documented yet when Danny was writing the PR - what would command line parsing look like to use CLI to have arbitrary depths of composition? Right now, you can have N top level imports but if you want to specify your imports imports, you need to do multiple `wac plug`. In WA.dev docs, Danny is going to create examples that go deep into everything you can do with the tooling and `wac`. Cool that can just send components with registries and now have a calculator CLI locally on my machine.
+* **Documentation on publishing to registries**: I don't think we will be able to document the publishing flow WITs to registries until better guidance is issued from the TOC.
+  * Calvin: we'd love to do a hackathon for the Cosmonic and Fermyon folks around the registry workflows
+* Maybe `wkg` should have `cargo [subcommand]` functionality as `wkg` subcommands. `wow` is another tool that allows you to run CLIs with Wasmtime within your workspace. `wkg` also needs to have feature flags if you want to ignore some of the heavier dependencies.
 
 ## Action Items