Source code structure
Every repository forked and maintained by Dasharo Release Team has following branch structure:
master
- follows upstream project master branch<platform>/release
- contains all code releases for given<platform>
, list of supported platforms is in Hardware Compatibility List section<platform>/rel_vX.Y.Z
- release branch for version X.Y.Z<platform>/develop
- contains most recent development and is periodically synced withmaster
branch<platform>/<feature>
- tracks development of platform specific feature
<platform> = <coreboot_mainboard_vendor>_<coreboot_mainboard_model>
if
platform is supported by coreboot, otherwise we use common sense and available
information about hardware.
Remotes
It is assumed that upstream repository is cloned and remote named dasharo
is
added later. This has to be done in order to pull git submodules from upstream
repository so they don't have to be kept on Dasharo's repository. This can be
done like this:
git clone https://review.coreboot.org/coreboot.git
cd coreboot
git submodule update --init --checkout
git remote add dasharo git@github.com:Dasharo/coreboot.git
If everything was done properly, this is expected state of remotes:
git remote -v
dasharo git@github.com:Dasharo/coreboot.git (fetch)
dasharo git@github.com:Dasharo/coreboot.git (push)
origin https://review.coreboot.org/coreboot.git (fetch)
origin https://review.coreboot.org/coreboot.git (push)
Tags
Dasharo Release tags in git repository use format: <platform>_vX.Y.Z
New platform support
Branch for new platform should be created from most recentmaster
branch tag.
If there is justified need to create support for new board at arbitrary
non-tagged commit developer should mark this commit with <platform>_v0.0.0
tag.
Force-pushes rules
Force-pushes to <platform>/rel_vX.Y.Z
, <platform>/develop
or
<platform>/<feature>
are forbidden with following exceptions:
- rebasing - when some other PR is merged to target branch before our does, or when upstream's master introduces the same fixes that our branch would
- squashing - to not produce unnecessary "fix indentation" or "add missing braces" commits to the history
- (re-)signing commits (both -S and -s) - shouldn't happen, but if it does happen it would be better to have it fixed by original author than the person that tries to upstream it some time later.
Force-pushes to <platform>/release
branches are unconditionally forbidden.
Merging guidelines
We want to keep the history linear. The rebase
merging strategy is desired.
Merge commits in the code repositories are not allowed. The rebase
strategy
should be the only one available in the GitHub web UI.
It is, however, strongly advised not to use GitHub web UI to perform code
merges. The signed-off
tends to be dropped (even when using the rebase
strategy), which is problematic for some projects (e.g. it makes the coreboot
lint checks fail after merging from the UI).
The procedure of merging is as follows:
- Review the code in GitHub.
- Make sure to receive at least one
Approve
in the review process. - Make sure that all change requests are resolved.
-
Merge the branch using git CLI. In case of merging the
feature
branch intodevelop
branch it may look as follows:git fetch dasharo git checkout dasharo/<platform>/develop -b <platform>/develop git merge --ff-only dasharo/<platform>/<feature> git push dasharo <platform>/develop
-
This should automatically trigger closing the MR in the GitHub web UI.
-
The remote branch can be safely deleted after this process.
git push dasharo --delete <platform>/<feature>
-
Note that the merging may fail if the source (in this case:
feature
) branch is not properly rebased on top of the target (in this case:develop
) branch. In such a case, one must rebase the source branch first:
git checkout dasharo/<platform>/<feature>
git checkout -b <platform>/<feature>
git rebase dasharo/<platform>/<develop>
git push -f dasharo <platform>/<feature>