* to quickly open the changes file.  By then we can also regex that path out of the description
     * in order to create a changes {@link File} for further use in this class.
     *
     * @param data the report data containing a description to parse
     * @return accepted api changes reported upon, as a file
     */

During server startup, prior to the server reporting healthy (via `/healthz`), not all API groups may be reported.
Wait for the server to report healthy (via `/healthz`) before depending on the information provided by the discovery APIs.

- E2e framework: added `--report-complete-ginkgo` and `--report-complete-junit` parameters. They work like `ginkgo --json-report <report dir>/ginkgo/report.json --junit-report <report dir>/ginkgo/report.xml`. ([#115678](https://github.com/kubernetes/kubernetes/pull/115678), [@pohly](https://github.com/pohly)) [SIG Testing]

Violations of the Code of Conduct can occur in any setting, even those unrelated to the project. We will only consider complaints about conduct that has occurred within one year of the report.


## Enforcement

# ADR-0001 - Use Architectural Decision Records

## Status

- ACCEPTED on 2023-12-01

## Context

In a distributed team with many subteams, the best solution to communicate decisions is to use a format accessible by everyone in charge of development.

We use *Specification* and *Discovery* documents stored in Google Drive, but they present some downsides:

regression that could incorrectly reject pods with OutOfCpu errors if they were rapidly scheduled after other pods were reported as complete in the API. The Kubelet now waits to report the phase of a pod as terminal in the API until all running containers are guaranteed to have stopped and no new containers can be started.  Short-lived pods may take slightly longer (~1s) to report Succeeded or Failed after this change. ([#108723](https://github.com/kubernetes/kubernetes/pull/108723), [@bobbypage](...

resolve and fix a reported vulnerability.

## Vulnerability Management Process

The vulnerability management process requires that the vulnerability report
contains the following information:

- The project / component that contains the reported vulnerability.
- A description of the vulnerability. In particular, the type of the
   reported vulnerability and how it might be exploited. Alternatively,

    }

    def "#member change should not be reported"() {
        expect:
        noViolation(rule)

        where:
        member << [Mock(JApiMethod), Mock(JApiField), Mock(JApiImplementedInterface), Mock(JApiConstructor)]
    }

    def "nothing should be reported if no changes"() {
        expect:
        noViolation(rule)
    }

    def "nothing should be reported if new interface is neither internal nor incubating"() {

    *   Experimental support for quantized models with the Android GPU delegate
    *   Add GPU delegate whitelist.
    *   Rename GPU whitelist -> compatibility (list).
    *   Improve GPU compatibility list entries from crash reports.
*   NNAPI
    *   Set default value for
        `StatefulNnApiDelegate::Options::max_number_delegated_partitions` to 3.
    *   Add capability to disable `NNAPI` CPU and check `NNAPI` Errno.

### Disclosure Process

MinIO uses the following disclosure process:

1. Once the security report is received one member of the security team tries to verify and reproduce
   the issue and determines the impact it has.
2. A member of the security team will respond and either confirm or reject the security report.
   If the report is rejected the response explains why.
3. Code is audited to find any potential similar problems.