Define Release Exception Process

[forhalle]

Once a stabilization branch is created, it is expected that no new features or breaking changes will be added to the stabilization branch. There are cases where completion may come in after the creation of stabilization, but is deemed important enough that we should consider including the feature.
We therefore need to create an easy to follow mechanism that clearly outlines who to contact, how to contact them, and what information should be included in the request for an exception. There should be an SLA attached to approval/denial response times.

Below is the suggested process for defining this mechanism:

• Gather a list of options via. a Discord discussion
• Document the options and a proposal
• Add an agenda item to the Release SIG meeting, present the proposal at the meeting, and drive to consensus

Acceptance Criteria:

• A published exception process
• Updates, as required, to the published point release process

[forhalle]

Here is a start to one potential solution to consider:

Request Process:

1. Verify the issue exists in the stabilization branch.
2. Complete the fix so that the blast radius is known.
3. Submit an o3de issue using a new to-be-created Exception Request template (see proposed format below). First, update the email Subject with the feature name, then fill out the information, then send.
4. Wait for the go-ahead from the Release Manager, who will verify all approvals are received, before merging into the stabilization branch.

Release Manager Process:

1. TBD - Need to define specifically who to obtain approval from, and the mechanism for requesting and tracking that approval.

Proposed Exception Request issue template:
Title: Exception Request: [add brief description here]
Body:

1. Destination Branch:
2. Component/SIG: (example: Prism/Build Sig)
3. Feature name and purpose: (example Linux Installer - allows users to easily install O3DE on Linux by downloading a package)
4. Impact Radius of change: This helps determine testing impact: (example This will affect most users on Linux). Include any details about discussions or coordination you may have already had with affected teams. For example, 'this feature primarily affects Networking, and we have already worked with Networking team to ensure 1) all existing Networking tests passed successfully and 2) no new tests needed to be written'
5. Risk: Risk of the change breaking and/or impacting other code and stability of the branch (example This change is deemed low risk as the installer is a 100% self-contained project, that could easily be pulled if high risk issues are found)
6. ETA on delivery: (example, we expect this code to be delivered by X date)
7. QA Efforts: Describe QA efforts that have/will be done to validate the change and reduce risk. Describe future planned QA effort for this change.
8. Additional Info: Anything else of noted that approvers should be aware of (e.g. this feature has been specifically requested by Bill Vass for reinvent)
9. PR: Provide a link to the PR for the merge into stabilization.

[tonybalandiuk]

Raised in sig-release meeting on 10/25 we should consider "fast tracking" exceptions. Is there a way to streamline the exception process for certain types of bug fixes and skip certain approvals?