Hello! Thanks for all the examples (LXQt [where I looked at the sources of lxqt-panel], git-remote-gcrypt, nbd, review, glibc).
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 In the other cases I did not see a real feedback loop where upstream developers would be exposed to Debian policy requirements or Debian QA. Seems many misunderstood my list of goals. My emphasis is not on the git branch layout or patch handling. So let me rephrase my goals from a quality assurance perspective: - 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. Now some ask, if it reasonable to require all upstream developers to follow Debian QA? No, I don't think so. If the CI runs automatically and the QA is automatic, then developers will be served with in-context errors and warnings at the time they are changing some code. For everybody to know the Debian Policy by heart and so on is naturally unreasonable, but reading a Lintian warning about a spelling error or broken multi-arch is not hard or unreasonable, and when those things are addressed the upstream code base benefits and all distributions benefit. The contrary is in my opinion unreasonable: to expect the Debian maintainer to fix tens of upstream issues at Debian import time that can be anything ranging like fixing a failing test suite or tracking down why the build is no longer reproducible. Yes, the maintainer could file N upstream bugs, but upstreams are less likely to fix them (as they might have switched context and don't want to revisit something they coded several months back) and even if upstreams fix them, the maintainer would need to wait some weeks, then manually cherry-pick and patch the Debian version, and then do extra work following up on all those patches and dropping or refreshing them on next upstream release. Having a debian/ in upstream, having deb building as part of the upstream CI, and keeping the delta of Debian debian/ and upstream debian/ as small as possible makes life much easier for the Debian maintainer, and in general all distros and the whole upstream code base benefits of the extra QA. - Otto
