proposed gbp.conf changes for Debian GNOME packages

Jeremy Bicha jbicha at
Tue May 15 19:24:37 BST 2018


It's been about 4 months since we've imported our packaging into git
and announced our workflow. [1] Since then, there have been some
suggestions about improvements to our workflow, so here are some
debian/gbp.conf additions I'd like to propose:


sign-tags = True

postimport = dch -v%(version)s New upstream release; git add
debian/changelog; debcommit

patch-numbers = False


(The postimport line is supposed to be one line but it will probably
be split by my mail client.)

For most packages, it feels like the patch numbers just get in the
way. They are possibly useful for packages with large numbers of
patches, so maybe some packages could opt in to it.

switch to gbp dch workflow
Before importing a new release, the first step should be to check the
git log for any changes not already in the changelog. If there are
changes, run something like
gbp dch; git add debian/changelog; git commit -m "Update changelog"

When you make commits in general, don't touch debian/changelog.

When it's time to release, run gbp dch -R. Now you can edit the
automatically generated changelog as needed. When you're satisified,
run git add debian/changelog; debcommit -r (or however you want to
commit and tag your release. Ubuntu in particular has to use gbp
buildpackage --git-tag-only to get release tags in the ubuntu/
namespace instead of debian/ ).

This dch workflow is preferred because it makes it easier to
cherry-pick fixes to different series (like for bugfixes for stable
releases) and it makes git revert work better. The tricky part is it
requires everyone to be aware of this workflow when doing releases or
commits won't be mentioned in the debian/changelog.

outdated git log filtering proposal
In a previous draft, I had this liine for git-buildpackage:

git-log = --no-merges --not --branches=upstream/*

But that didn't work as well as an explicit changelog bump commit like
I proposed in the postimport line. It might be nice if
git-buildpackage handled this for us but I think this way works well
enough. I mentioned the line just in case anyone was curious about
trying to handle our situation differently.

Let me know what you think. If there is agreement and there aren't
major objections, I'll update the wiki this weekend and start updating
packages then too.


Jeremy Bicha

More information about the pkg-gnome-maintainers mailing list