One of the things that I've been wondering about is whether it would make
sense to have a configuration file in Debian packages that allows
maintainers to specify preferences for contributions. At the
moment, this is not a well-formed proposal yet - but I'm curious as to
your thoughts.
lintian-brush has its own configuration file
(debian/lintian-brush.conf) that carries some of these preferences -
but they're not really specific to lintian-brush. Ideally this is
something that we can standardize on (DEP?) and that is honored by
various tools and services.
Possible settings include:
* What Debian/Ubuntu release to stay compatible with,
to ease backporting. ("compat-release" in lintian-brush.conf)
* Whether or not contributors can feel free to reformat
files (e.g. wrap-and-sort -a -v).
("allow-reformatting" in lintian-brush.conf)
* Whether to update the changelog or leave that up to
"gbp dch". ("update-changelog" in lintian-brush.conf)
* Whether to include the upstream VCS history in the "upstream"
branch
Where these aren't explicitly set (almost all packages), lintian-brush
by default uses a combination of heuristics ("update-changelog" is
autodetected by looking at Git commit history) and being reasonably
conservative (never reformat, stay compatible with stable).
In practice, I have found that:
* "update-changelog": the autodetection in lintian-brush works well
now (after a few iterations)
* "allow-reformatting": lintian-brush isn't able to edit some control
files because it can't preserve formatting (~5% of the total). It
just skips these.
* "compat-release": this is hard to autodetect, and one of the main
reasons for feedback on merge proposals.
A reasonably obvious solution would be to standardize a
"debian/contributing" file (RFC822 style?) that can look something like
this:
Allow-Reformatting: yes
Compatibility-Release: oldstable
However, while straightforward, I'm not sure if this is the right approach:
* Generally speaking, the preferences would be the same for
all packages maintained by a specific team/person. Having to copy
these preferences into every git repository in a set (e.g.
perl-team) seems tedious and unnecessarily repetitive. Maybe this
should live in a separate database somewhere, or perhaps it can be
specified in salsa somehow on a per-team basis?
The janitor has a policy file that currently captures some of these
preferences, but it's service-specific and not really usable by
other tools. https://salsa.debian.org/jelmer/debian-janitor/-/blob/master/policy.conf
(look for "--compat-release" and "changelog:")
* Should this really be a separate file, or could it be folded
in elsewhere?
* Allowing maintainers to specify preferences might also make it more
likely that packaging habits diverge - and that could it make it
harder rather than easier to contribute to packages. At the very
least, we should be careful what sort of preferences can be
specified.
* A lot of these things can be detected with heuristics. In a
way, adding a configuration file is an easy way out - instead of
getting these tools to just do the right thing without making a
human edit a file.
"allow-reformatting" is irrelevant if tools that edit control
files can perfectly preserve existing formatting. Perhaps it's
possible to autodetect what release to maintain backwards
compatibility with as well?
Cheers,
Jelmer
--
Jelmer Vernooij <jelmer@jelmer.uk>
PGP Key: https://www.jelmer.uk/D729A457.asc
Attachment:
signature.asc
Description: PGP signature