davidlt/kernel-ark
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Update Maintainer Guide

Jeremy Cline 2020-03-11 15:48:42 +00:00
parent 733d35bdfd
commit 52a9cc485c
1 changed files with 21 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
Maintainer-Guide.md

@ -1,10 +1,18 @@
This guide covers common maintenance tasks and is primarily aimed at kernel maintainers.
This guide covers common maintenance tasks and is primarily aimed at kernel maintainers. It assumes you have write access to https://gitlab.com/cki-project/kernel-ark.git and the remote in your clone is called "upstream", as set up in the quick start guide.
# Rebasing
The repository is used for both the Fedora kernel and the RHEL Always Ready kernel (ARK). Thus, it contains two sets of configurations, as well as two sets of downstream patches. Fedora is a superset of ARK, so it's patches are applied on top of ARK's patches.
This guide assumes you have write access to https://gitlab.com/cki-project/kernel-ark.git and the remote in your clone is called "upstream", as set up in the quick start guide.
Every release requires the maintainer to:
Rebasing the kernel involves the following steps:
1. Rebase the downstream kernel patches
2. Update the configuration
3. Create a release branch and tags
Once that is done, the result can be imported into a dist-git repository and built in Koji.
# Rebasing Patches
There are two branches containing downstream kernel patches. `ark-patches` is based on Linus's master branch. `fedora-patches` is then based on top of `ark-patches`.
## ARK Kernel Patches
@ -17,6 +25,10 @@ The rebase consists of the following steps:
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``
## Fedora Kernel Patches
Once `ark-patches` has been rebased, repeat the process with `fedora-patches`, except this time rebase onto `ark-patches`: `git rebase ark-patches fedora-patches`
### Common Problems
There are a few issues that can occur during the patch rebase.
@ -29,7 +41,7 @@ Once a dropped patch has a fix, submit a merge request to ``ark-patches`` with t
#### Patch Applies But Is Broken
This problem occurs less frequently, but is less straightforward to detect and fix. A patch might cleanly apply, but an interface it uses has changed in some way (e.g. a function got renamed). Ideally the change causes the build to fail.
This problem occurs less frequently, but is also less straightforward to detect and fix. A patch might cleanly apply, but an interface it uses has changed in some way (e.g. a function got renamed). Ideally the change causes the build to fail.
Assuming you know how to fix the problem, use the following approach:
@ -40,26 +52,17 @@ Assuming you know how to fix the problem, use the following approach:
An example of this is https://gitlab.com/cki-project/kernel-ark/merge_requests/90.
## Fedora Patches
At the moment, the Fedora kernel is maintained directly in the dist-git and we are importing the patches to keep in sync.
1. ``git checkout fedora-patches``
2. ``git reset --hard <upstream-tag>``
3. Import the latest Fedora Rawhide patches from the Fedora [dist-git](https://src.fedoraproject.org/rpms/kernel): ``grep ^Patch $FEDORA_DISTGIT/kernel.spec | awk -vdistgit="$FEDORA_DISTGIT" '{print distgit $2}' | xargs git am``
4. ``git push -f upstream fedora-patches``
## Configuration
# Configuration
1. ``git checkout internal``
2. ``git pull``
3. ``git merge <upstream-tag>``
4. ``make rh-configs-commit``
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 5: ``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``
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``
## Release branch
# Release branch
Once the kernel patches and configuration have been updated for the new release, it's time to create the release branch: