1. Review the merge request. If you see anything questionable, kick it back to "needs review" or "needs work", unassign it from yourself, and leave a comment. If the patch introduces changes that need manual updating from site admins, be sure that the issue has a change record associated with it. Also be sure that tests are passing; don't merge an issue with failing tests unless there's a documented reason why you need to in this case.
1. Review the merge request. If you see anything questionable, kick it back to "needs review" or "needs work", unassign it from yourself, and leave a comment. If the patch introduces changes that need manual updating from site admins, be sure that the issue has a change record associated with it. Also be sure that tests are passing; don't merge an issue with failing tests unless there's a documented reason why you need to in this case.
3. If it looks good, go through the issue and assign credit as you see fit.
2. If it looks good, go through the issue and assign credit as you see fit.
4. Adjust the issue title as desired for maximum clarity, since it will be the commit message.
3. Adjust the issue title as desired for maximum clarity, since it will be the commit message.
5. Save changes to the issue.
4. Save changes to the issue.
6. Scroll to the bottom of the issue and merge it.
5. Scroll to the bottom of the issue and merge it.
7. If you're going to backport the issue to the current release branch, read on; otherwise, leave a nice comment and mark the issue fixed -- you're all set.
6. If you're going to backport the issue to the current release branch, read on; otherwise, leave a nice comment and mark the issue fixed -- you're all set.
### How to backport
### How to backport
...
@@ -14,3 +14,9 @@
...
@@ -14,3 +14,9 @@
3. Cherry-pick the latest commit from the release branch (e.g. `git cherry-pick 1.x`). If there are merge conflicts, fix them if they're straightforward, and continue the cherry-pick (`git add . && git cherry-pick --continue`). If they're _not_ straightforward, abort the cherry-pick (`git cherry-pick --abort`) and kick the issue to "Patch (to be ported)", and ask for a new MR targeting the release branch.
3. Cherry-pick the latest commit from the release branch (e.g. `git cherry-pick 1.x`). If there are merge conflicts, fix them if they're straightforward, and continue the cherry-pick (`git add . && git cherry-pick --continue`). If they're _not_ straightforward, abort the cherry-pick (`git cherry-pick --abort`) and kick the issue to "Patch (to be ported)", and ask for a new MR targeting the release branch.
4. Adjust `project_template/composer.json`, and the various `composer.json` files in the component recipes, to account for the component(s) being changed by the current patch. For example, if the patch is fixing a bug (or bumping a dependency) in `drupal_cms_ai`, and the _next_ version of Drupal CMS will be 1.0.3, then you'll want to change `project_template/composer.json`, which depends on `drupal_cms_ai`, so that its requirement is `"drupal/drupal_cms_ai": "~1.0.3"`. You'll need to do this for everything that depends on the component(s) being changed. This is tedious, but necessary.
4. Adjust `project_template/composer.json`, and the various `composer.json` files in the component recipes, to account for the component(s) being changed by the current patch. For example, if the patch is fixing a bug (or bumping a dependency) in `drupal_cms_ai`, and the _next_ version of Drupal CMS will be 1.0.3, then you'll want to change `project_template/composer.json`, which depends on `drupal_cms_ai`, so that its requirement is `"drupal/drupal_cms_ai": "~1.0.3"`. You'll need to do this for everything that depends on the component(s) being changed. This is tedious, but necessary.
5. Add those changes to the most recent commit: `git add . && git commit --amend`. Push the branch (`git push`).
5. Add those changes to the most recent commit: `git add . && git commit --amend`. Push the branch (`git push`).
### Tips
* In commit messages, always refer to specific recipes or components by their _machine name_. For example, `drupal_cms_starter` instead of `Starter recipe`. This just makes it a little easier to know, at a glance, what has been changed.
* Credit is assigned subjectively, but feel free to err on the side of "credit everybody".
* T possible "commit types" are `feat` (feature), `fix`, `chore`, and `ci`.
