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.
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,58 @@ 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. Keeping the process of merging from upstream without rebases +might make a future rebase more time consuming or harder to do, due growing +number of conflicts which happens with the ever growing changing of the tree, +which makes this periodic rebasing more desirable, and moves any needed conflict +resolution back into our patches on top of upstream and not on upstream merges +only. + +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
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1387#note_6805991...
There is a long run-on sentence here. Can we break it up? One suggestion (starting at 'Keeping the process......upstream merges only'): "" 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. ""
The spirit of the above is to lay out our reasons for performing a developer impacting rebase. And then acknowledging that we understand this negatively impacts developers. Followed by our desire to continue to evolve this process.
Feel free to re-word/write my suggestion. :-) Thoughts?
From: Don Zickus on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1387#note_6806024...
@jmflinuxtx - i want to document our reasons for doing the rebase. With that knowledge, I believe it helps others improve our process if they stumble upon a better way then what we do now. Can you review Herton's opening statement and/or my suggested improvements to see if they capture our reasons?
kernel@lists.fedoraproject.org