Re: Best practices for Debian developers who are also upstreams?
Otto Kekäläinen <otto@debian.org> writes:
> 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 basically maintain notmuch that way.
[snip]
> 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
I do have debian in the upstream repo. salsa CI is currently not working
due to an obscure bug involving emacs and docker. I do provide an
upstream build target to make snapshot packages to help people test. And
we use travis, but only to test the upstream builds.
> - have the delta of Debian debian/ an upstream debian/ as small as possible
This is generally zero. I guess it comes down to definition. There is no
seperate Debian debian/ dir as far as I'm concerned.
> - fix all bugs detected in Debian directly at upstream when possible
Sure. I typically make point/micro releases for non-debian specific
problems. Although the package is non-native for flexibility, I mostly
treat it as native.
> - when not possible, fix them "locally" first in Debian and eventually
> have it upstreamed
I'm not sure I follow you precisely, but in my case I make a branch in
the upstream repo for e.g. stable updates.
> - bonus: import upstream releases as git operations without having to
> export and import tar.gz packages
I have only one git repo, so there's no importing per se.
Reply to: