Establish a metric of success for the early branch creation

Context

The monthly release process does not allow enough time for QA or emergency fixes before the final release. The code that will be released to our customers is tested in production only for a few hours, and only with the specific configuration and feature flags we have on GitLab.com, resulting in bugs shipping with the monthly release and poor customer experience.

Automate the creation of monthly releases in pr... (gitlab-com/gl-infra/software-delivery&1 - closed) will move the active stable branch generation one week earlier in the release schedule to allow for thorough testing and timely backports. This will increase the quality, safety, and reliability of the monthly release while enabling a better developer experience and confidence.

Establish a measure of success for the early branch creation

With the early active branch creation, we're expecting an increase in release quality, given more time to QA. The purpose of this issue is to establish metrics to keep track of the impact of the monthly release procedures.

Possible metrics:

• Number and severity of bug / security fixes for the current version in the first patch
• Number and severity of bug / security fixes in subsequent patches (relying on &971 (closed)).

Exit criteria

• Determine metrics of success
• Keep track of said metrics for N releases.
• Analyze