Hi, 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:
============= [buildpackage] sign-tags = True [import-orig] postimport = dch -v%(version)s New upstream release; git add debian/changelog; debcommit [pq] patch-numbers = False ============= (The postimport line is supposed to be one line but it will probably be split by my mail client.) patch-numbers ------------------- 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: [dch] 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. conclusion ------------- 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. [1] https://wiki.debian.org/Gnome/Git https://lists.debian.org/debian-gtk-gnome/2018/01/msg00001.html Thanks, Jeremy Bicha
