Otto Kekäläinen <o...@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.
