Re: Possible DEP proposal - contribution preferences
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
Reply to: