[SRU F/G/U 0/3] Enforce all annotations

[Thadeu Lima de Souza Cascardo]

On Wed, May 20, 2020 at 12:46:31PM +0200, Stefan Bader wrote:
> On 20.05.20 12:23, Thadeu Lima de Souza Cascardo wrote:
> > On Wed, May 20, 2020 at 09:12:05AM +0200, Stefan Bader wrote:
> >> On 18.05.20 15:36, Thadeu Lima de Souza Cascardo wrote:
> >>> BugLink: https://bugs.launchpad.net/bugs/1879327
> >>>
> >>> Start enforcing all config annotations. This is implemented as an opt-in
> >>> for now, that each branch may set as default. After all branches are fixed
> >>> up to set it by default, we can turn it into an opt-out.
> >>>
> >>> It's set to true for the master branch as it builds fine with Focal.
> >>> Unstable, however, might break, but I am sending the opt-in patch for
> >>> Unstable as well, nonetheless.
> >>>
> >>> Thadeu Lima de Souza Cascardo (3):
> >>>   UBUNTU: [Config]: do not enforce CONFIG_VERSION_SIGNATURE
> >>>   UBUNTU: [Config]: prepare to enforce all
> >>>   UBUNTU: [Config]: enforce all config options
> >>>
> >>>  debian.master/rules.d/hooks.mk   |  1 +
> >>>  debian/rules                     |  1 +
> >>>  debian/rules.d/4-checks.mk       |  3 ++-
> >>>  debian/scripts/config-check      | 12 ++++++++----
> >>>  debian/scripts/misc/kernelconfig |  2 +-
> >>>  5 files changed, 13 insertions(+), 6 deletions(-)
> >>>  create mode 100644 debian.master/rules.d/hooks.mk
> >>>
> >> IMO this should be first getting applied to G/U and when there are no surprises,
> >> this could be added to Focal as a next step.
> >>
> >> -Stefan
> >>
> >>
> > 
> > One of the challenges here is that unstable development process is more prone
> > to failures, as it's constantly rebased on top of new upstream versions, full
> > of config changes.
> > 
> > This is really a stable feature, preventing config regressions. I could submit
> > it to all series, but thought restricting it to focal was a better idea, as it
> > would: 1) restrict to only one series; 2) focal master already has all config
> > and annotations match.
> > 
> > Of course, this should be applied first to unstable, but not sure that waiting for
> > "no surprises" there will work.
> > 
> > This is certainly going to change some of the stable process, potentially
> > causing more build failures than before, as config options change without the
> 
> And this is my point exactly. There is already enough struggle to get things
> done. Not really keen on adding more build failures to the world of pain.
> 
> -Stefan
> 

Hence, my proposal of only applying this to focal only (and not all the other
stable series). If that isn't enough compromise, what satisfactory "no
surprises" result do you expect?

Please, take in consideration what I already brought up (unstable having more
config changes than usual).

Cascardo.

> > respective annotations change. Isn't that what we want it to do? In order to
> > catch unreviewed changes or even regressions?
> > 
> > Cascardo.
> > 
> 
>