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 with
<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.
It is assumed that upstream repository is cloned and remote named
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 email@example.com:Dasharo/coreboot.git
If everything was done properly, this is expected state of remotes:
git remote -v dasharo firstname.lastname@example.org:Dasharo/coreboot.git (fetch) dasharo email@example.com:Dasharo/coreboot.git (push) origin https://review.coreboot.org/coreboot.git (fetch) origin https://review.coreboot.org/coreboot.git (push)
Dasharo Release tags in git repository use format:
New platform support
Branch for new platform should be created from most recent
master 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>/<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.
<platform>/release branches are unconditionally forbidden.
We want to keep the history linear. The
rebase merging strategy is desired.
Merge commits in the code repositories are not allowed. The
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
signed-off tends to be dropped (even when using the
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
Approvein the review process.
- Make sure that all change requests are resolved.
Merge the branch using git CLI. In case of merging the
developbranch 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>