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

Marcelo Henrique Cerri marcelo.cerri at canonical.com
Thu May 21 14:24:19 UTC 2020


On Wed, May 20, 2020 at 07:56:39AM -0300, Thadeu Lima de Souza Cascardo wrote:
> 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).

I agree with Cascardo. It would be less painful to include that on a
stable kernel and in fact it's a justified pain, since it will help us
to catch silent regressions that otherwise wouldn't be noticed.

>
> Cascardo.
> 
> > > respective annotations change. Isn't that what we want it to do? In order to
> > > catch unreviewed changes or even regressions?
> > > 
> > > Cascardo.
> > > 
> > 
> > 
> 
> -- 
> kernel-team mailing list
> kernel-team at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/kernel-team

-- 
Regards,
Marcelo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200521/dfa7ae2f/attachment.sig>


More information about the kernel-team mailing list