for including it in the “.0” release. Otherwise, the PRs will not be merged until after the release.
* For large fixes (>100 LOC that’s not from generated files), SMEs from that area must also approve the PR.

## Bug Fixes

* Bug fixes will not be merged in until the first release has been published, unless it addresses a critical issue.
* All changes should have an associated GitHub issue and/or a release note.

You can [contribute](../CONTRIBUTING.md) by picking an
[unassigned open issue](https://github.com/istio/istio/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fenvironments%2Foperator+no%3Aassignee),
creating a [bug or feature request](../BUGS-AND-FEATURE-REQUESTS.md),
or just coming to the weekly [Environments Working Group](https://github.com/istio/community/blob/master/WORKING-GROUPS.md)
meeting to share your ideas.

name: Bug report
description: Report a bug to help us improve Istio
body:
  - type: markdown
    attributes:
      value: |
        Thanks for taking the time to fill out this bug report!
  - type: checkboxes
    id: security-check
    attributes:
      label: Is this the right place to submit this?
      description: |-
        This is used to report product bugs:

# disable_pgv: disables protoc-gen-validation. This is not used buts adds many MB to Envoy protos
# not set vtprotobuf: this adds some performance improvement, but at a binary cost increase that is not worth it for the agent
AGENT_TAGS=agent,disable_pgv
# disable_pgv: disables protoc-gen-validation. This is not used buts adds many MB to Envoy protos
# vtprotobuf: enables optimized protobuf marshalling.

while there are a few exceptional cases that should behave differently, for the most part any divergence from the reference code results in bugs....

- [istio/ztunnel](https://github.com/istio/ztunnel). The repository contains the Rust implementation of the ztunnel
component of Ambient mesh.

## Issue management

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

- **Epic**. An epic represents a feature area for Istio as a whole. Epics are fairly broad in scope and are basically product-level things.

			NodeName: NodeName,
		},
		Status: corev1.PodStatus{
			PodIP: "11.1.1.12",
		},
	}
	ns := &corev1.Namespace{
		ObjectMeta: metav1.ObjectMeta{Name: "test"},
		// TODO: once we if the add pod bug, re-enable this and remove the patch below
		//		Labels: map[string]string{constants.DataplaneModeLabel: constants.DataplaneModeAmbient},

	}

	client := kube.NewFakeClient(ns, pod)

There are a few ways to prevent these:

	"istio.io/istio/operator/cmd/mesh"
	"istio.io/istio/pkg/cmd"
	"istio.io/istio/pkg/collateral"
	"istio.io/istio/pkg/config/constants"
	"istio.io/istio/pkg/log"
	"istio.io/istio/tools/bug-report/pkg/bugreport"
)

const (
	// Location to read istioctl defaults from
	defaultIstioctlConfig = "$HOME/.istioctl/config.yaml"
)

const (
	FlagCharts = "charts"
)

          # Tests can do anything
          - "!$test"
          # Main code should only be used by appropriate binaries
          - "!**/operator/**"
          - "!**/istioctl/**"
          - "!**/tools/bug-report/**"
          # This should only really import operator API, but that is hard to express without a larger refactoring
          - "!**/pkg/kube/**"
          - "!**/pkg/url/**"
          - "!**/pkg/test/framework/**"