Joe Bowbeer

FYI - Rather than adding the CRDs to each github release as assets, they are [pushed](https://github.com/emissary-ingress/emissary/blob/master/manifests/push_manifests.sh) to an S3 bucket: ``` https://app.getambassador.io/yaml/emissary/3.9.1/emissary-crds.yaml => ... => https://datawire-static-files.s3.amazonaws.com/yaml/emissary/3.9.1/emissary-crds.yaml ```

Currently, the OTEL Metrics SDK spec documents `shutdown` and `forceFlush` as two separate methods, with no interdependencies: https://opentelemetry.io/docs/specs/otel/metrics/sdk/#shutdown Are you proposing that `MeterProvider.shutdown()` should be spec'd to call `MeterProvider.forceFlush()`? Or...

The current CIS EKS benchmark recommends running bottlerocket, and bottlerocket supports something along these lines: https://github.com/bottlerocket-os/bottlerocket/issues/2731

Related discussion: https://github.com/OpenFunction/OpenFunction/discussions/517

Not stale. Isn't OCI and cosign a requirement for kubernetes-sig org?

Exit code 137 is OOM (out of memory)

License Compliance is the only hitch?

@jspiro what's the status of this? > While I appreciate the existence of github_branch_protection_v3, once the graphql API is usable for big orgs, we'll have the same migration nightmare back...

I am considering migrating from docker compose build to docker bake, but we also use skaffold for local dev, so I was wondering whether to migrate from docker compose build...

It looks like #625 caused a regression To be clear, the informer only needs list/watch access, not read (get) access to secrets. See #605 and https://github.com/kedacore/keda-docs/issues/1307 for previous discussion about...