Hello Otto,
On Sat 08 Feb 2020 at 10:07PM +02, Otto Kekäläinen wrote:
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the upstream development version (=upstream git master)
> and then have only a very small overhead work then importing and
> uploading new upstream releases in Debian.
>
> Is somebody else already doing something similar like this?
> Any tips, blogs, examples on the topic?
>
>
> I find it annoying to carry Debian patches for bugs that could be
> fixed globally at upstream, and it is also annoying when something
> Debian QA catches is broken at upstream and I find it out only at the
> time I am preparing an upload to Debian.
>
> My goals would be:
> - have debian/ in upstream repository, and a CI that does the bulk of
> Debian QA on every upstream commit and immediately gives feedback to
> upstream devs that "break" something from Debian QA point of view
> - have the delta of Debian debian/ an upstream debian/ as small as possible
> - fix all bugs detected in Debian directly at upstream when possible
> - when not possible, fix them "locally" first in Debian and eventually
> have it upstreamed
> - have it easy to compare Debian and upstream debian/ contents
> - bonus: import upstream releases as git operations without having to
> export and import tar.gz packages
>
> I have in rdiff-backup pretty much this setup already in place but I
> have some challenges on how to handle the debian/changelog file and a
> couple of other details. I would be very keen to learn from others
> before inventing too much of new.
I do this with the package git-remote-gcrypt (and some others). I don't
try very hard to separate my upstream and Debian hats. It hasn't been a
problem so far.
I use a single branch for upstream releases and the -1 Debian uploads.
If there are commits to the upstream source, and -2, -3 etc. uploads to
Debian before there is an upstream release, I just represent the
divergence with two git branches, which can be merged back together for
the next upstream release and -1 upload.
In order to avoid the problem of discovering Debian problems only after
tagging a new upstream release, this sbuild rune can build the package
without an .orig.tar:
alias sbuild-prerelease="sbuild --dpkg-source-opts='-Zgzip -z1 --format=1.0 -sn'"
You can add --run-autopkgtest and --run-piuparts to that.
So, you could have your CI running that on all commits.
(credits to Ian Jackson for the rune)
To do an upstream release and -1 upload, I do this:
- `git merge` any -2, -3 etc. uploads to Debian of the last upstream
release; this updates debian/
+ relies on `dpkg-mergechanglogs` to be enabled
- finalise Debian -1 changelog and upstream changelog, and git commit
both
+ for git-remote-gcrypt they're actually the same file but that's for
historical reasons
- git tag -s 1.2
- git deborig
- sbuild and upload
- start a 1.3-1 debian changelog entry and a 1.3 upstream changelog
entry, and commit those
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature