Re: Best practices for Debian developers who are also upstreams?
On 2020-02-08 22:07:48, Otto Kekäläinen wrote:
> Hello!
>
> 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 maintain a few packages in Debian for which I am also the (mostly
solo) upstream:
* feed2exec
* gameclock
* monkeysign
* undertime
Those packages are all *native* packages, in that they *don't* have a -N
suffix in the version number. This is generally frowned upon, but in my
situation, it's been helpful because I don't need to worry about
"upstream" vs "debian": everything is "in Debian".
This implies that I have only one debian/ directory: the upstream. When
I need to make a release, I push it to unstable. If I need to make a
hotfix release for security or stable, I make a branch. I use semantic
versionning and basically maintain a "major" version per Debian release
(as necessary, which is "rarely").
> 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.
I do both at once, all the time, as part of CI and the release
process. I do the Debian checklist before I even push tags upstream, but
sometimes things come up in Debian after I pushed the tag. Then I just
make another patch release, no big deal.
> 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
The tricky part here is generating a new version without mangling
debian/changelog all the time. I haven't found a great story for that
that works with git, but maybe you can generate syntetic commits to fake
a new Debian package version in CI.
> - have the delta of Debian debian/ an upstream debian/ as small as
> possible
For me, there's no diff. It's the same branch, same code. I do, however,
generate debian/changelog only on release so I don't have to repeat
myself between commit logs (in git) and release notes (in
debian/changelog).
> - fix all bugs detected in Debian directly at upstream when possible
Not sure what that means, but when I fix a bug in Debian, it's fixed in
"upstream" first, ie. I push it to git, and I tag it as "pending" in the
BTS to make it clear it will be fixed in the next upload.
> - when not possible, fix them "locally" first in Debian and eventually
> have it upstreamed
I never have to do that. To fix it "first in Debian", I just make a new
upstream release. If it's on a previous "branch" (e.g. stable), I make a
release on that branch.
For example right now undertime is 1.7.0 in buster and 1.8.0 in
bullseye/sid. Next RC bugfix release is 1.8.1 in sid and 1.7.1 in
buster, and I would have a 1.7.x branch to follow buster (which I
haven't needed yet).
> - have it easy to compare Debian and upstream debian/ contents
Trivial. It's my different maintenance branches.
> - bonus: import upstream releases as git operations without having to
> export and import tar.gz packages
I export tarballs only as part of the release process and otherwise
don't bother with those artefacts at all.
> 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.
The changelog is the hard part. I update it only on release which
simplifies things tremendously, but will make CI harder, as I mentioned
before.
Also, this is not for everyone: it makes it hard for Debian folks to
send updates to the git repository (because it might not be on
debian.org infra) and inversely it makes it hard for "upstream" to make
a release if they're not Debian developers. Fortunately, I am both and
those are mostly solo projects so that hasn't been an issue so far.
When it will be, the package will just go non-native and follow more
usual development practices. This happened to etckeeper when joeyh left
us, for example.
I hope that helps!
A.
--
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
- Montesquieu, Lettres persanes
Reply to: