Re: Best practices for Debian developers who are also upstreams?
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
Reply to: