Update Maintainer Guide

Jeremy Cline 2020-03-24 13:59:46 +00:00
parent fb515576f8
commit 786646f56b

@ -6,7 +6,7 @@ Every release requires the maintainer to:
1. Rebase the downstream kernel patches
2. Update the configuration
3. Create a release branch and tags
3. Create a release branch/tags
Once that is done, the result can be imported into a dist-git repository and built in Koji.
@ -16,10 +16,12 @@ The downstream kernel patches are in a branch called `ark-patches`. This branch
The rebase consists of the following steps:
1. Rebase the kernel patches: `git rebase <upstream-tag> ark-patches`.
2. If a patch fails to apply and the fix is clear, go ahead and fix it. Otherwise, file an [issue](https://gitlab.com/cki-project/kernel-ark/issues) for each patch that does not apply with the commit hash and conflict details so it can be resolved later.
3. If rebasing onto a tag, create a branch for this revision of the kernel patches. This is useful when comparing the state of the patches between versions: ``git branch ark/patches/<upstream-tag> && git push upstream ark/patches/<upstream-tag>``.
4. ``git push -f upstream ark-patches``
1. Update master: `git checkout master && git reset --hard linus/master`
2. Rebase the kernel patches: `git rebase master ark-patches`.
3. If a patch fails to apply and the fix is clear, go ahead and fix it. Otherwise, file an [issue](https://gitlab.com/cki-project/kernel-ark/issues) for each patch that does not apply with the commit hash and conflict details so it can be resolved later.
4. If rebasing onto a tag, create a branch for this revision of the kernel patches. This is useful when comparing the state of the patches between versions: ``git branch ark/patches/<upstream-tag> && git push upstream ark/patches/<upstream-tag>``.
5. `git push upstream master`
6. `git push -f upstream ark-patches`
### Common Problems
@ -46,25 +48,27 @@ An example of this is https://gitlab.com/cki-project/kernel-ark/merge_requests/9
## Configuration
1. ``git checkout internal``
2. ``git pull``
3. ``git merge <upstream-tag>``
4. ``make FLAVOR=fedora rh-configs-commit && make FLAVOR=rhel rh-configs-commit``
5. ``git push upstream internal``
6. ``./redhat/gen_config_patches.sh``
7. Open a merge request for each branch created in step 6: ``git branch | grep configs/"$(date +%F)" | xargs git push -o merge_request.create -o merge_request.target=internal -o merge_request.remove_source_branch upstream``
Once the patches are rebased, update the configuration branch:
1. `git checkout internal`
2. `git pull`
3. `git merge master`
4. `make FLAVOR=fedora rh-configs-commit && make FLAVOR=rhel rh-configs-commit`
5. `git push upstream internal`
6. `./redhat/gen_config_patches.sh`
7. Open a merge request for each branch created in step 6 (if any): ``git branch | grep configs/"$(date +%F)" | xargs git push -o merge_request.create -o merge_request.target=internal -o merge_request.remove_source_branch upstream``
## Release branch
Once the kernel patches and configuration have been updated for the new release, it's time to create the release branch:
1. ``git checkout -b ark/<upstream-tag> ark/patches/<upstream-tag>``
2. ``git merge internal``
3. Ensure the branch can at least build the SRPM: ``make rh-srpm``
4. ``touch localversion``
5. ``make rh-release``
6. ``make rh-release-tag``
7. ``git push upstream <upstream-tag> ark/<upstream-tag> ark/patches/<upstream-tag> kernel-<version>-<release>``
1. `git checkout -b ark/<upstream-tag> ark/patches/<upstream-tag>`
2. `git merge internal`
3. Ensure the branch can at least build the SRPM: `make rh-srpm`
4. `touch localversion`
5. `make rh-release`
6. `make rh-release-tag`
7. `git push upstream <upstream-tag> ark/<upstream-tag> ark/patches/<upstream-tag> kernel-<version>-<release>`
8. `git checkout ark-latest && git reset --hard ark/<upstream-tag> && git push -f upstream ark-latest`