Update README.md (#19991)

Give better instructions to fix and check for patch readiness that
matches what we do today.

---------

Co-authored-by: Martin Angers <martin.n.angers@gmail.com>
This commit is contained in:
George Karr 2024-06-26 14:39:31 -05:00 committed by GitHub
parent bc6fc85113
commit c0d8e1f99e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194

View file

@ -45,9 +45,11 @@ If there are no product changes, and the DRI decides to prioritize the story, th
> We prefer the term engineering-initiated stories over technical debt because the user story format helps keep us focused on our users and contributors.
### Fix a bug
All bug fix pull requests should have a mention back to the issue they resolve with #<ticket_number> in the description or even in a comment. Please do not use any [automated words](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) since we don't want the tickets auto-closing when PR's are merged.
If the bug is labeled `~unreleased bug`, branch off and put your PR into `main`. These issues can be closed as soon as they complete QA.
If the bug is labeled `~released bug`, branch off the tag for the latest release of Fleet and put your PR into `main`. For example, `git checkout fleet-v4.48.2`, then `git checkout -b my-bug-fix-branch`. These issues are not closed until the next release of Fleet. This approach makes sure the bug fix is not built on top of unreleased feature code, which can cause merge conflicts during patch releases.
If the bug is labeled `~released bug`, branch off and put your PR into `main`. After merging checkout the latest tag, for example `git checkout fleet-v4.48.2`, then `git fetch; git cherry-pick <commit>`. If the cherry-pick fails with a conflict call out in the ticket how to resolve or if it is sufficiently complicated call out this fix is not suited for the patch release process and should only be included in the end of sprint release. This approach makes sure the bug fix is not built on top of unreleased feature code, which can cause merge conflicts during patch releases.
### Begin a merge freeze
To ensure release quality, Fleet has a freeze period for testing beginning the Tuesday before the release at 11:00 AM Pacific. Effective at the start of the freeze period, new feature work will not be merged into `main`.