On 2/8/20 7:57 PM, Simon Richter wrote: > In my experience, it was often a good idea to separate my upstream and > Debian hats.
+1 My current situation is that I'm a Debian packager who has then over time become more involved in upstream and eventually ended up with a commit bit. On a different package, I'm in the process of taking over packaging for something where I am already an upstream developer (or perhaps should say "was", as I haven't been active upstream in some time, though that may change here). That sounds like it may be different than your situation, but I hope I can still offer some useful comments. > 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. +1. In such a case, you can clean that up into a more general solution for upstream and later drop the Debian patch. I've had that exact thing happen. >> - 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'm in the process of packaging something where upstream (which is not me) puts their debian directory (for CI purposes) as packaging/debian. That allows them to do real Debian packaging for CI, and update that as necessary, but keeps it out of the way of the real "debian" directory. You might consider that option. Upstream's CI presumably has to move/copy/link ./packaging/debian to ./debian before kicking off the Debian build, but that's just one extra step. >> - bonus: import upstream releases as git operations Do this either way! :) In the packages I maintain, my debian/README.source says: The `master` branch is upstream's `master` branch. ... The `upstream/latest` branch contains the unpacked contents of the orig tarball. It is branched off the `master` branch, so the delta from `master` (at the branch point) to `upstream/latest` contains generated files that exist in the tarball but not in the upstream repository. That said, I prefer to keep separate git checkouts for the package and upstream to avoid the potential for accidents like pushing upstream pull request branches to Debian Salsa or, far more likely, accidentally pushing the current master to Debian Salsa. > 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, I'm a big fan of using git-buildpackage and `gbp dch`. My current workflow (somewhat "copied" from e.g. lintian) is that debian/changelog contains a stub like this until it is time to tag a Debian package release: ntpsec (1.1.8+dfsg1-4+git) UNRELEASED; urgency=medium * UNRELEASED -- Richard Laager <rlaa...@wiktel.com> Sat, 11 Jan 2020 22:49:28 -0600 Note that it is critical that the version in Salsa NOT be the same as the version in the archive if you are using Salsa CI to test changes. That's why the +git is added. If they are the same, when the CI code tries to install the package, you'll have problems because of the conflicting version numbers. -- Richard
signature.asc
Description: OpenPGP digital signature
