• Possible DEP proposal - contribution preferences

    From Jelmer =?utf-8?Q?Vernoo=C4=B3?=@21:1/5 to All on Fri Jan 29 14:40:02 2021
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEEsjhixBXWVlpOhsvXV5wWDUyeI+gFAmAUDCYACgkQV5wWDUye I+hqAA//TW/G+0ZvEXZSduy1eUdABrX3aP3kdE05rjaC+MNp9/n0IZ7ltk7MT1xN CRpB3D4TrocLBWp0d3kSTCNDUe1xdA9Y5v5VmcaThC7KL16yevVmHuTpLWnNPT6B AihFYIqQFthaHPTUEAp+aFn5uh7zs+3JFIXyjoQI1UEtk1HxnCcsg3dnrAQ4CzPM TI0rl6y6/Wdp/uvRHiJN8/mx2DMbHhUmphvAOONuGIABsxdRoD17hWdWAZAjBr+c eJAmao/DcoZVE6If7urUENexCwYJNUpFXjS08J/yUKyFMIYPXOJZOOjHBVtysr+7 qzSNQ55ydNGPh0plT234dMKoppsXOwC8IA6ToRrbFU6N81s05JzxYjsffCMnjRBq m/49WOB8nztvYpW8ijBLZnc2N4wM6wVm45Up5Z83MzPWMP9U7lJ/bkpbiCv61Va7 drxm7skp5r6KTjjiQBprSZKa3/DaEp2Q6xKfokM/lL2/dQ4pYR069yhnm5c5Dt8n i3HfZub/nD4+0Zs7JLvmf66alTRjoUb58mQFlUmie78MUsQ82VIo8jGdmDqzXi32 SAFMiMUx4cGY2+pP4No2SgQBzF8rBJps3/aNRroKITaqlWexqme/4Fl5v8pP6xdE 5+JFRKZWGRye5c4+OHSuCi24uGt3GayS/bxtiH/Xx/z8FObl5Xo=
    =xPQt
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)