Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Niels Thykier (2021-02-10 17:35:36)
> Russ Allbery:
> > Jonas Smedegaard  writes:
> > 
> >> Let's see if Debian can agree on a single normalization of 822-ish 
> >> files.  For starters, I disagree that "wrap-and-sort -a" is a 
> >> suitable normalization, as that will involve re-indentation when 
> >> keys change. Instead, I propose this as starting point:
> >>
> >>   wrap-and-sort -ast
> > 
> > I've been using wrap-and-sort -ast on all of my packages for a 
> > while, with much the same justification.
> > 
> > My recollection is that the relevant Config::Model model has a 
> > slightly different preferred normalization form?  Those are the two 
> > most common tools used for this, I think, so if the two of them 
> > could agree, that would go a long way towards having a common format 
> > (and this may have already happened without me knowing).
> > 
> 
> Personally, I would be fine with a variant of wrap-and-sort (-bastk or
> there abouts) being a Debian-wide recommendation/default *if*
> wrap-and-sort would preserve comments.

Ah, right.

I totally forgot that, and agree that auto-killing comments is a no-go.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Possible DEP proposal - contribution preferences

[Niels Thykier]

Russ Allbery:
> Jonas Smedegaard  writes:
> 
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting point:
> 
>>   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.
> 
> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).
> 

Personally, I would be fine with a variant of wrap-and-sort (-bastk or
there abouts) being a Debian-wide recommendation/default *if*
wrap-and-sort would preserve comments.

A case where comments are important to me is the d/control of debhelper,
where I document the rationale for many of the versioned
(build-)dependencies.  It would be a non-starter for me to maintain
those comments elsewhere simply because wrap-and-sort keeps steam
rolling them into oblivion.

~Niels

Re: Possible DEP proposal - contribution preferences

[Jelmer Vernooij]

On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> > 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.
> 
> I must say that we keep adding layers of complexity and this would
> just extend the amount of things that one should know about packaging.
> 
> We need more consistency and not more choices. But in the end, those
> choices are differences that do already exist in practice.
> 
> In the grand scheme of things, we should have a Debian-wide
> recommended way of handling packages and this configuration file
> would only be needed when a maintainer really wants to deviate from
> this recommended way.
> 
> The DEP we need is the one that defines this default way of handling
> packages and contributions, and the file you want would only be a
> by-product of this.

On Tue, Feb 09, 2021 at 06:21:46PM +0100, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >  * Whether or not contributors can feel free to reformat
> >files (e.g. wrap-and-sort -a -v).
> >("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.
> It apparently works quite well for python as a whole ecosystem, where
> now pretty much nobody is "against" pep8 (or even black!).  There is no
> reason we can't manage to decide on a wrapping format and stick with it.

The argument you're both making is that we should have a single sensible
standard and then provide a way for those packages that currently
diverge (and possibly want to diverge in the future?) for specifying
so. That makes a lot of sense, and it would mean that:

* the cost of adding this file is only borne by those who diverge from
  the standard
* requiring per-package files is less costly - larger teams could
  (should?) just stick to the standard - and there is less need to
  support a complicated per-team configuration

That addresses the main concerns I raised in my original message.

Using heuristics to figure out the style for a package is somewhat at
odds with defining defaults in the absence of explicit configuration.

However, in the absence of explicit configuration we can still use
heuristics to determine that the explicit configuration or standards
are blatantly not being followed by the package and acting
appropriately. This could result in:

 1) not reformatting according to the selected style, i.e.
making changes but not reformatting, if supported by the tool
 2) formatting according to whatever other style is being followed
(and detected)[1]
 3) simply refusing to make any changes until the user reformats using
the (explicit or default) configured style

I don't think this needs to be explicitly mandated in the DEP, but it
would be relevant for any actual implementations of the DEP for the
reasons mentioned by Jonas in
https://lists.debian.org/debian-devel/2021/02/msg00138.html

On Mon, Feb 08, 2021 at 10:29:13PM +0100, Raphael Hertzog wrote:
> On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> >  * 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?
> Somehow this ship has sailed, plenty of teams do commit debian/gbp.conf
> and debian/salsa-ci.yml in all their repositories. At least the GitLab CI
> has an URL include mechanism that makes it possible to create a team-wide
> configuration and include it.
Agreed that it's a common practice to have the same files duplicated
for all of the packages maintained by a specific team, but it still
doesn't seem ideal...

Since this is a common practice for other control files that would
benefit from per-team configuration, perhaps that's a problem that
should be solved separately for all of these files rather than
as part of this DEP.

> >  * Should this really be a separate file, or could it be folded
> >in elsewhere?
> I don't know of anything else but if we create a new file, I'd rather have
> it in debian/source/ rather than right below debian.
+1.

What about one of:

* debian/source/style
* debian/source/preferences
* debian/source/contrib

Once these standards are defined and diverge can be specified, lintian
could also check for packages confirming to the standards.

Some of the things to standardize:

 * a canonical style for debian control files and .dirs, .docs,
   

Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Thomas Goirand (2021-02-09 20:48:12)
> On 2/9/21 6:21 PM, Mattia Rizzolo wrote:
> > On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >>  * Whether or not contributors can feel free to reformat
> >>files (e.g. wrap-and-sort -a -v).
> >>("allow-reformatting" in lintian-brush.conf)
> > 
> > On this, please also read https://bugs.debian.org/895570#13
> > 
> > tl;dr: I honestly believe we should just decide on a format, and
> > converge towards it.
> > It apparently works quite well for python as a whole ecosystem, where
> > now pretty much nobody is "against" pep8 (or even black!).  There is no
> > reason we can't manage to decide on a wrapping format and stick with it.
> 
> I've been flamed a few times for (ab)using wrap-and-sort in some teams,
> I do believe it's not justified. Sometimes, it's up to a point one can
> hardly read the dependency list...

Tools like wrap-and-sort are certainly a no-go for NMUs!

Yes, it is harder for me to read packages not maintained in _my_ style, 
but really I have *no* say on styling when only a quest making changes 
to a package maintained by someone else.

If a package is too hard for me to help edit, then that is a reason so 
not NMU that package, not a reason to re-style the package!


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Possible DEP proposal - contribution preferences

[Russ Allbery]

Thomas Goirand  writes:
> On 2/9/21 7:40 PM, Russ Allbery wrote:

>> I've been using wrap-and-sort -ast on all of my packages for a while, with
>> much the same justification.

>> My recollection is that the relevant Config::Model model has a slightly
>> different preferred normalization form?  Those are the two most common
>> tools used for this, I think, so if the two of them could agree, that
>> would go a long way towards having a common format (and this may have
>> already happened without me knowing).

> For packages generating a lot of binaries, the -b option is also quite
> useful, don't you think?

I'd support that.  I only recently became aware of it.

-- 
Russ Allbery (r...@debian.org)  

Re: Possible DEP proposal - contribution preferences

[Thomas Goirand]

On 2/9/21 7:40 PM, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
>> Let's see if Debian can agree on a single normalization of 822-ish
>> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
>> normalization, as that will involve re-indentation when keys change.
>> Instead, I propose this as starting point:
> 
>>   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.
> 
> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).

For packages generating a lot of binaries, the -b option is also quite
useful, don't you think?

Cheers,

Thomas Goirand (zigo)

Re: Possible DEP proposal - contribution preferences

[Thomas Goirand]

On 2/9/21 6:21 PM, Mattia Rizzolo wrote:
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
>>  * Whether or not contributors can feel free to reformat
>>files (e.g. wrap-and-sort -a -v).
>>("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.
> It apparently works quite well for python as a whole ecosystem, where
> now pretty much nobody is "against" pep8 (or even black!).  There is no
> reason we can't manage to decide on a wrapping format and stick with it.

I've been flamed a few times for (ab)using wrap-and-sort in some teams,
I do believe it's not justified. Sometimes, it's up to a point one can
hardly read the dependency list...

What probably would make things a bit better, would be a lintian warning
that would compare the source package, and it's result after running
"wrap-and-sort -bastk", and then yell if there's a difference,
suggesting strongly to use wrap-and-sort.

I never wrote a lintian thing, does anyone want to implement it? It
should be super easy for anyone comfortable with Lintian, I guess... no?

Cheers,

Thomas Goirand (zigo)

Re: Possible DEP proposal - contribution preferences

[Mattia Rizzolo]

On Tue, Feb 09, 2021 at 10:40:39AM -0800, Russ Allbery wrote:
> Jonas Smedegaard  writes:
> 
> > Let's see if Debian can agree on a single normalization of 822-ish
> > files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
> > normalization, as that will involve re-indentation when keys change.
> > Instead, I propose this as starting point:
> 
> >   wrap-and-sort -ast
> 
> I've been using wrap-and-sort -ast on all of my packages for a while, with
> much the same justification.

Indeed, same here :)

> My recollection is that the relevant Config::Model model has a slightly
> different preferred normalization form?  Those are the two most common
> tools used for this, I think, so if the two of them could agree, that
> would go a long way towards having a common format (and this may have
> already happened without me knowing).

That's exactly what I'm saying in the above bug.
That bug asks to change wrap-and-sort's defaults, and my answer is
saying that if the default change, we should do the same to cme.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Russ Allbery]

Jonas Smedegaard  writes:

> Let's see if Debian can agree on a single normalization of 822-ish
> files.  For starters, I disagree that "wrap-and-sort -a" is a suitable
> normalization, as that will involve re-indentation when keys change.
> Instead, I propose this as starting point:

>   wrap-and-sort -ast

I've been using wrap-and-sort -ast on all of my packages for a while, with
much the same justification.

My recollection is that the relevant Config::Model model has a slightly
different preferred normalization form?  Those are the two most common
tools used for this, I think, so if the two of them could agree, that
would go a long way towards having a common format (and this may have
already happened without me knowing).

-- 
Russ Allbery (r...@debian.org)  

Re: Possible DEP proposal - contribution preferences

[Jonas Smedegaard]

Quoting Mattia Rizzolo (2021-02-09 18:21:46)
> On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> >  * Whether or not contributors can feel free to reformat
> >files (e.g. wrap-and-sort -a -v).
> >("allow-reformatting" in lintian-brush.conf)
> 
> On this, please also read https://bugs.debian.org/895570#13
> 
> tl;dr: I honestly believe we should just decide on a format, and
> converge towards it.

> It apparently works quite well for python as a whole ecosystem, where 
> now pretty much nobody is "against" pep8 (or even black!).  There is 
> no reason we can't manage to decide on a wrapping format and stick 
> with it.

Heh, I am not surprised that users of the scripting language driven by 
"There should be one-- and preferably only one --obvious way to do it" 
are more comfortable than most in aligning to a single normalization.

Let's see if Debian can agree on a single normalization of 822-ish 
files.  For starters, I disagree that "wrap-and-sort -a" is a suitable 
normalization, as that will involve re-indentation when keys change.  
Instead, I propose this as starting point:

  wrap-and-sort -ast


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Re: Possible DEP proposal - contribution preferences

[Mattia Rizzolo]

On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
>  * Whether or not contributors can feel free to reformat
>files (e.g. wrap-and-sort -a -v).
>("allow-reformatting" in lintian-brush.conf)

On this, please also read https://bugs.debian.org/895570#13

tl;dr: I honestly believe we should just decide on a format, and
converge towards it.
It apparently works quite well for python as a whole ecosystem, where
now pretty much nobody is "against" pep8 (or even black!).  There is no
reason we can't manage to decide on a wrapping format and stick with it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Raphael Hertzog]

Hi Jelmer,

On Tue, 02 Feb 2021, Jelmer Vernooij wrote:
> 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.

I must say that we keep adding layers of complexity and this would
just extend the amount of things that one should know about packaging.

We need more consistency and not more choices. But in the end, those
choices are differences that do already exist in practice.

In the grand scheme of things, we should have a Debian-wide
recommended way of handling packages and this configuration file
would only be needed when a maintainer really wants to deviate from
this recommended way.

The DEP we need is the one that defines this default way of handling
packages and contributions, and the file you want would only be a
by-product of this.

>  * 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?

Somehow this ship has sailed, plenty of teams do commit debian/gbp.conf
and debian/salsa-ci.yml in all their repositories. At least the GitLab CI
has an URL include mechanism that makes it possible to create a team-wide
configuration and include it.

>  * Should this really be a separate file, or could it be folded
>in elsewhere?

I don't know of anything else but if we create a new file, I'd rather have
it in debian/source/ rather than right below debian.

>  * 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.

+1

>  * 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.

Indeed.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Possible DEP proposal - contribution preferences

[Adrian Bunk]

On Tue, Feb 02, 2021 at 09:57:11PM +0100, Philipp Kern wrote:
> On 2021-02-02 16:48, Adrian Bunk wrote:
> > A debhelper compat bump is a breaking change that must not be done
> > without the maintainer verifying that it didn't introduce any
> > regression.
> > 
> > This is the whole point of compat levels.
> > 
> > Unfortunately there is a lack of recognition how many bugs are
> > introduced by blindly updating debhelper compat levels - staying
> > at a deprecated compat level is better than a not properly tested
> > compat bump.
> 
> To be fair: You can assert statically if the compat bump did not introduce
> any changes

This is actually an area where good tooling would be helpful.

Status quo with automated compat bumps is that many maintainers do not 
even notice before the upload if this change did make one of the binary 
packages become empty - even such breakages that do add lintian warnings
often slip through.

> (by compiling twice).

This is not sufficient to catch all regressions caused by a compat bump.
As an example, dh_missing defaulting to --fail-missing in compat 13 has 
been a very common source of "binary-all FTBFS" in recent months.

> Kind regards
> Philipp Kern

cu
Adrian

Re: Possible DEP proposal - contribution preferences

[Bernd Zeimetz]

On 2/2/21 4:48 PM, Adrian Bunk wrote:
> A debhelper compat bump is a breaking change that must not be done 
> without the maintainer verifying that it didn't introduce any
> regression.
> 
> This is the whole point of compat levels.
> 
> Unfortunately there is a lack of recognition how many bugs are 
> introduced by blindly updating debhelper compat levels - staying
> at a deprecated compat level is better than a not properly tested
> compat bump.

I'm less concerned about compat levels, usually these things produce
failing builds or the package is just not comparable to the one you had
before.


But I think(!) what people bump easily is the Standards Version without
checking anything. Lintian is happy if you change the number...


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Possible DEP proposal - contribution preferences

[Philipp Kern]

On 2021-02-02 16:48, Adrian Bunk wrote:

A debhelper compat bump is a breaking change that must not be done
without the maintainer verifying that it didn't introduce any
regression.

This is the whole point of compat levels.

Unfortunately there is a lack of recognition how many bugs are
introduced by blindly updating debhelper compat levels - staying
at a deprecated compat level is better than a not properly tested
compat bump.


To be fair: You can assert statically if the compat bump did not 
introduce any changes (by compiling twice).


Kind regards
Philipp Kern

Re: Possible DEP proposal - contribution preferences

[Adrian Bunk]

On Tue, Feb 02, 2021 at 01:55:19PM +, Jelmer Vernooij wrote:
> 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.
>...

What kind of contributions exactly are you referring to?

For team-maintained packages, I would expect the team to communicate the 
rules when accepting a new team member.

For one-time contributions like patches or NMUs the general policy has
always been to try to keep the changes reasonably small.

> 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.
>...

I would rather say it would be a problem if we end up having many
tools editing the same files.

> * What Debian/Ubuntu release to stay compatible with,
>   to ease backporting. ("compat-release" in lintian-brush.conf)
>...

A debhelper compat bump is a breaking change that must not be done 
without the maintainer verifying that it didn't introduce any
regression.

This is the whole point of compat levels.

Unfortunately there is a lack of recognition how many bugs are 
introduced by blindly updating debhelper compat levels - staying
at a deprecated compat level is better than a not properly tested
compat bump.

> Cheers,
> 
> Jelmer

cu
Adrian

Possible DEP proposal - contribution preferences

[Jelmer Vernooij]

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 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature