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