-
Notifications
You must be signed in to change notification settings - Fork 6
Home
This article describes the workflow of openSUSE's grub2 package, by leveraging the build service's obs_scm source service the source is directly mirrored from remote source code manager (scm) like git, rather than extracting from tarball archive.
The gnu grub is the upstream git repository from which openSUSE grub is forked and code stream branches are based. The first step should always be to get the patch to the upstream project so that downstream patch maintenance work can be reduced with rebasing to new upstream release.
About how to contribute patch to grub upstream, you'll have to subscribe to grub-devel mailing list where patch is sent for maintainer's review.
The OBS project for developing grub2's new obs_scm workflow is currently in
home:michael-chang:github:test grub2-opensuse
The GitHub project managing openSUSE's grub2 source working with above OBS project.
The rpm directory contains alternate sources and build description file like spec file not part of grub source itself. They are exported to root of rpm directly and also part of source rpm.
Please do not commit changes in rpm directory mixed with others, because we might split changes in the future if we decided to make it an indepent project. Also it makes life easier to know the delta with upstream by filtering it out as unrelated folder.
git log --oneline origin/master..HEAD -- . ':!rpm'
- master: tracking branch of upstream's master branch
The branch used to manage product development history has a specical meaning and is usually mentioned as code stream branch.
- opensuse/[generation]: The openSUSE code stream
- sle*/[generation]: The SLE code stream
Since it is much related to openSUSE build service as central hub for most developing works taking place, some rules must be taken in order to have the integrated workflow running smoothly.
The generation is a counter increased by each rebase to new upstream tag. Using generation we can easily trace back given code stream's ancestor and review for changes. It is required as we may lost changes in rebasing branches.
If you branch from a code stream branch to develope your features and want to submit it back, please rebase your feature on to code stream branch and send pull request. We don't want to introduce merge commits in code stream as history could become complicated overtime. On the other hand keeping the history linear helps us to know the delta from upstream.
Doing force push to code stream branch is prohibited. We will enable branch protection feature to prevent accepting it accidently. If you want to revert a commit, use git revert command. If you want to fix broken commits, use git commit --fixup or git commit --squash to have it obvious in the commit message. We will tidy them up in the event of rebaseing to new upstream tag and those command helps to get things done in an automated way.
The alias branch may be used to simply daily task. For eg, the opensuse/latest is an alias to latest branch of openSUSE code stream. The sle15sp3/1 is an alias to opensuse/latest before GA milestone to help obeying factory first policy. The sle15sp3/1 code stream branch is created later to GA release for managing maintenace code stream.
As usual, no change.
osc bco home:michael-chang:github:test grub2 <your_home_project>
cd <your_home_project>/grub2
You can still work with quilt for applying patch series with the source archive generated by the source service in the local checkout directory. Please keep in mind that this is only for testing purpose using patch local to the OBS project. You should always send your patch upstream as well as pull request to the openSUSE grub2 project whenever your patch been verified to fix an issue.
First run osc service localrun
osc service localrun
The entire grub source git is cloned into the grub directoy, and you can create a testing branch named foo from there. You are now fully empowered by git.
cd grub
git checkout -b foo
To build the test rpm with the foo branch, you have to modify the _service to use the foo branch in the revision element.
<param name="revision">foo</param>
Rerun the source service locally, it will use source cloned previously as the cache, so no worries all your local changes persist. And please remember to delete old grub obscpio and tarball as they are going to be replaced by new one.
rm grub-*.obscpio grub-*.tar.xz
osc service localrun
osc addremove
If you have a look on grub2.changes it also gets updated with your changes.
- Update to version 2.04_126_g892c6ac9f:
* foo
To build remotely on OBS server, run
osc commit
To build locally the rpm package against openSUSE_Factory, run
osc build openSUSE_Factory
The OBS source service has support for git submodule. With submodule, git repository can reside in directory of another, even nested.
Here we're evaluating the plan of managing obs related stuff as submodule which helps to have separated history. The downside is more time consuming than exporting them through the extract parameter as part of the checkout files from the main repository.
Moreover submodule makes it complicated to the workflow as pull requests needs to be in sequence for different git repositories.
To quote my favorite paragraph somewhere in the document.
The result of the services should become part of the source package and the history. However it should not possible to change these files directly to avoid lost work, when the service is generating a new file.
The changelog is generated since a given parent revision which is controlled by changesrevision element in the _\ servicedata xml file. If for some reason you want it to be generated from different parent, for eg, fork point of your testing branch, you can modify it to what you need but remember to rerun service to make it effective.
- Add description to each file used by obs_scm
- Add rule to git commit --fixup and git revert
- Add description for rebase will skip commits that is also part of upstream