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

Update Maintainer Guide

Jeremy Cline 2020-03-20 19:21:22 +00:00
parent 71d0a3fcb7
commit 6d79a24ec7
1 changed files with 23 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
Maintainer-Guide.md

@ -1,6 +1,6 @@
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.
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.
The repository is used for both the Fedora kernel and the RHEL Always Ready kernel (ARK). Thus, it contains two sets of configurations.
Every release requires the maintainer to:
@ -10,25 +10,17 @@ Every release requires the maintainer to:
Once that is done, the result can be imported into a dist-git repository and built in Koji.
# Rebasing Patches
## Rebasing Kernel 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
The ``ark-patches`` branch contains the latest version of the patches being carried for the Always Ready Kernel.
The downstream kernel patches are in a branch called `ark-patches`. This branch is regularly rebased onto Linus's master branch.
The rebase consists of the following steps:
1. Rebase the kernel patches: ``git rebase <upstream-tag> ark-patches``.
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``
## 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.
@ -52,7 +44,7 @@ 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.
# Configuration
## Configuration
1. ``git checkout internal``
2. ``git pull``
@ -62,7 +54,7 @@ An example of this is https://gitlab.com/cki-project/kernel-ark/merge_requests/9
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``
# 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:
@ -76,11 +68,13 @@ Once the kernel patches and configuration have been updated for the new release,
8. `git checkout ark-latest && git reset --hard ark/<upstream-tag> && git push -f upstream ark-latest`
# Building
## Building
After a release branch has been prepared, it's time to build it. This guide assumes you have Koji and/or Brew installed and properly configured. It also assumes you've authenticated and have permissions to build.
## Fedora
### Fedora
This requires having fedpkg installed.
From the release branch, run:
@ -88,6 +82,7 @@ From the release branch, run:
# Checks out the Fedora dist-git repository and copies everything from the source tree into it
#
# By default, this creates a directory in /tmp, but the location can be set with RHDISTGIT_TMP.
# If you already have a local clone of the Fedora dist-git repository, it can be used with RHDISTGIT_CACHE=<path-to-repo>.
make rh-dist-git
cd /tmp/RHEL*/kernel
@ -96,14 +91,18 @@ fedpkg push
fedpkg build
```
## ARK
### ARK
1. Run ``make rh-dist-git``. By default, this will create a directory in /tmp and can be overridden with `make RHDISTGIT_TMP=/path/to/dir rh-dist-git`. The directory name will be printed at the end, it should end with /kernel . It may look like this: /tmp/RHEL8.2018-10-08.HXzpLdpW/kernel. The next time you are building dist-git, you may edit redhat/Makefile.rhpkg and use cache to make the process faster. This is done by setting RHDISTGIT_CACHE:=<path2distgit> where path2distgit is the path to previous make rh-dist-git output.
2. ``cd /tmp/RHEL-8*/kernel``
3. ``vim ../changelog ../diff``. Confirm the changelog includes the changes for this release and looks reasonable.
4. ``git diff --cached``. Final check to make sure things look correct.
5. ``git commit -a -s -F ../changelog``
6. ``rhpkg push``
7. ``rhpkg build --target temp-ark-rhel-8-test --skip-nvr-check``
This requires having rhpkg-sha512 installed and brew.
From the release branch, run:
1. `make DIST=elrdy rh-dist-git`.
2. `cd /tmp/RHEL-8*/kernel`
3. `vim ../changelog ../diff`. Confirm the changelog includes the changes for this release and looks reasonable.
4. `git diff --cached`. Final check to make sure things look correct.
5. `git commit -a -s -F ../changelog`
6. `rhpkg push`
7. `rhpkg build --target temp-ark-rhel-8-test --skip-nvr-check`
8. ``rhpkg tag -F ../changelog``
9. ``git push origin <tag>``