Create release branch

From postmarketOS
Jump to navigation Jump to search

This is relevant for maintaining the repository only, regular users will not need this guide.

Creating a new release branch

Checklist

Creating a new release branch, like "v20.05":

  • git checkout -b v20.05 master
  • git push
  • protect the new release branch in gitlab, so nobody can force-push to it
  • remove channels.cfg (should only be in master)
  • adjust channel in pmaports.cfg
  • replace "master" in .gitlab-ci.yml (example)
  • remove packages:
    • device/testing
    • cross/*-armhf, cross/*-x86
    • unused firmware packages (see script below)
  • run pmbootstrap aportgen for packages in cross
  • add the new branch to master's channels.cfg
  • bpo
    • add the branch to bpo's config, for x86_64 only
    • wait until all packages for x86_64 are built and published, fix packages as necessary
    • after x86_64 is published, activate more arches (if you activate them before, the builds will fail due to missing cross compilers!)

Remove unused firmware packages

After removing device/testing/*, the related firmware packages should be removed as well. This script adds them for removal, read it, run it, then do git status and git commit.

#!/bin/sh -e
PMAPORTS=~/code/pmaports

# $1: pkgname
firmware_mentioned_anywhere() {
	local pkgname="$1"

	cd "$PMAPORTS"
	for dir in *; do
		[ -d "$dir" ] || continue
		[ "$dir" = "firmware" ] && continue
		
		git -C "$dir" grep -q "$pkgname" && return 0
	done
	return 1
}

cd "$PMAPORTS/firmware"
for i in *; do
	if firmware_mentioned_anywhere "$i"; then
		echo "# $i was found"
	else
		git rm -r "$PMAPORTS/firmware/$i"
	fi
done
echo "# done"

Maintenance

Cherry-picking commits from master

  • In merge requests, that shall be cherry picked, add the cherry-pick-to-stable label. It is the responsibility of the person doing the merge, to also cherry pick it to the stable branch.
  • Use git cherry-pick -x ffffffff (insert commit to cherry pick accordingly). The -x will add a (cherry picked from commit ffffffff) line to the commit message.
  • Cherry picked commits shall not be squashed, then it's hard to understand which commits were already picked and which were not.
  • If git reports conflicts, resolve them.
    • If you have cherry-picked a commit, that has touched a lot of devices that don't exist in the stable branch, then you can use git rm $(git status | grep "deleted by us" | cut -d ':' -f 2).
    • Look at the git diff to make sure that the result is as expected.
  • If it's something non-trivial, then make a merge request for the cherry-picked commits so we see that it was done correctly, it builds and that we may test the packages before merging.
  • Avoid cherry-picking multiple patches that touch the same pmaports in the wrong order (related comment).