Hi, On 08.02.20 21:07, 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. In my experience, it was often a good idea to separate my upstream and Debian hats. If your packages are part of a stable release, this effectively forces you to split off a stable branch from whatever is in the archive at freeze time, so it might be a good idea to package a LTS branch instead of the latest release. At the same time, Debian packages have a well-defined installation procedure, so it is often possible to build a quick fix for a bug that will give users a working package, but where the patch is not suitable for upstream inclusion, like changing an init script or unit file. > - 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 Would that mean that upstream developers are expected to update the packaging when they make a breaking change, or do you have a workflow that permits leaving the packaging in a broken state until someone gets around to fixing the packaging? Does that scale for multiple distributions? > - have the delta of Debian debian/ an upstream debian/ as small as possible > - have it easy to compare Debian and upstream debian/ contents If you keep a debian/ directory in upstream sources, it should not be allowed to diverge at all -- anything else just leads to confusion after checkout, and people building broken packages. Since there are multiple distributions using the Debian package format, this also means you can only support one of them in the upstream repo, and all others need to find a patch workflow to implement their local changes. > - bonus: import upstream releases as git operations without having to > export and import tar.gz packages Not much of a bonus though -- the Debian archive still requires a proper release archive anyway for offline use. > 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. Maintaining debian/changelog inside a version control system is a bit of a category error, because it is a form of version control system log, although one that lists far fewer individual commits, and where commits addressing multiple issues are encouraged. Stacking two version control systems on top of each other behaves roughly as well as tunneling TCP/IP inside TCP/IP: works most of the time, but hiccups amplify each other. Last but not least: package uploads should be spun from releases that "upstream" feels have the required quality level. We have very few "rolling release" packages in the archive, because users only complain about them being outdated and buggy at the same time, and updating to a different snapshot would freeze them at a different point in time with different bugs. Ideally, a release has had a bit more extensive testing upstream than just "passes CI". Simon
signature.asc
Description: OpenPGP digital signature
