From: Herton R. Krzesinski herton@redhat.com

redhat: add documentation about the os-build rebase process

We have been rebasing os-build lately on each new major Linux upstream release. Add general instructions/guideline on how to do the rebase process on top of last upstream tag/commit.

This also provides an explanation on why we are doing the rebase, provided by Don Zickus.

Signed-off-by: Herton R. Krzesinski herton@redhat.com

diff --git a/redhat/docs/maintaining.rst b/redhat/docs/maintaining.rst index blahblah..blahblah 100644 --- a/redhat/docs/maintaining.rst +++ b/redhat/docs/maintaining.rst @@ -128,6 +128,66 @@ above Fedora build.

To kick off manually run

+Rebasing +-------- + +When a new major version of Linux is released upstream, we can rebase the +os-build branch. + +Rebasing from time to time, helps reduce the clutter of the extra changes +on top of upstream and future merge conflicts. This periodic rebase addresses +the needs of the Fedora community's desire to separate upstream from Fedora +specific changes, helps keep it clear what patches changed in the final form +upstream, and what a Fedora specific patch looks like currently as opposed to +split across various conflict patches. + +While rebasing has a negative effect on developer contribution, we believe +saving the rebase for the end of release cycle allows for minimal developer +contribution disruption while gaining the above advantages. + +This process is open to feedback for improvements. + +To do the os-build rebase, the following steps can be done: + +:: + + # Create a rebase branch from latest os-build branch and start the process + # For any conflicts that arise, check and fix them, following git instructions + git fetch origin + git checkout -b rebase origin/os-build + marker=$(cat redhat/marker) + git rebase $marker + + # After you finish the rebase, check the results against the current os-build + git diff origin/os-build.. + # If there are differences shown, you might have fixed conflicts wrongly or + # in a different way. To fix, you may want to add extra on top commits and + # rebase again interactively + <make change related to a previous commit to make it equal os-build> && git add + # create dummy commit + git commit + # You may need to create more than one commit, if changes are related to + # more than one previous commit. Then squash commits into the existing + # previous commits related to the change with: + git rebase -i $marker + + # Now cleanup any commits that we might have reverted, and release commits. + # When editor opens with the commit list in interactive mode, search for any + # commits starting with "Revert " in the subject and if they match a previous + # commit which is being reverted, you can remove both. For release commits, + # search commits with subject starting with "[redhat] kernel-" and delete/ + # remove them. + git rebase -i $marker + + # Check results again doing a diff against os-build branch. Because of cleanup + # in the previous step, some differences will appear now, and that's ok + # because of the removal of the release commits. The only differences that + # should appear are on Makefile.rhelver, redhat/kernel.changelog and + # redhat/marker + git diff origin/os-build.. + + # If differences shown are expected, we are ok and rebase is done. + ::

TODO FILL ME IN

-- https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1387