Hello, On Sun 09 Feb 2020 at 10:57PM +02, Otto Kekäläinen wrote:
> Most interesting was perhaps Seans git-remote-gcrypt. You even have a > rpm spec file included which helps illustrate this is a true upstream > and not a fully native Debian package. > > There does not seem to be any automation around release numbering — > currently the repo tags, debian/changelog and redhat spec file all > bumped manually and independently. > https://github.com/spwhitton/git-remote-gcrypt/commit/069f6ea33149fbaa8bd83423b7a7b591fcfed43b Indeed. If the package was more active I would implement some script which would bump all the versions, which could be run right after releasing. > - Build .deb directly at upstream for every upstream commit: allow > upstream developers to notice if they break Debian packaging to the > level that it stops building. Upstream PRs (or MRs) should not be > accepted if they make changes without considering if they break .deb > (or .rpm if that is also included in the upstream repository). > Effectively this requires that upstream git master branch has a > debian/ directory. > > - Since there will be a debian/ directory, upstream might as well run > full Debian QA on every commit. This will help detect if upstream > developes make grave mistakes, like try to run curl/git fetches > duringthe build stage, introduce library symbols in a wrong way or > embed in the build something that stops from being a reproducible > build anymore. Lintian even complains about spelling mistakes. Such QA > items are not Debian specific – all code everywhere should be without > spelling mistakes, all programs should stay reproducible if they now > are so etc. Right. My sbuild-prerelease alias could be used in your CI to do this. -- Sean Whitton
signature.asc
Description: PGP signature
