linux-kernel - Re: linux-next: build failure after merge of the btrfs tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20211029121409.GX20319@suse.cz>
Date:   Fri, 29 Oct 2021 14:14:09 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: linux-next: build failure after merge of the btrfs tree

On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> On Friday, October 29, 2021, David Sterba <dsterba@...e.cz> wrote:
> 
> > On Fri, Oct 29, 2021 at 11:52:26AM +0200, David Sterba wrote:
> > > On Wed, Oct 27, 2021 at 09:09:24PM +1100, Stephen Rothwell wrote:
> > > > Hi all,
> > > >
> > > > [I am not sure why this error only popped up after I merged Andrew's
> > > > patch set ...]
> >
> >
> 
> 
> 
> > Also I think that next time you can use some older version of the
> > for-next branch instead of making the whole subsystem depend on BROKEN.
> > This causes much more harm in the testing setups that suddenly can't
> > work at all, compared to testing a few days older branch.
> 
> The Linux Next reflects current state of affairs and marking something
> which is definitely broken as BROCKEN is what I expect as a developer who
> tests some other stuff on top of broken code.

I'd argue against using the big 'depdends BROKEN' hammer as much as
possible, surely not for linux-next. Normaly the BROKEN status is earned
after known unfixed breakage for subsystems where nobody cares. If code
is buggy and causes crashes when testing linux-next, that's something we
want to see, not "no test results at all".

Can you imagine all compilation breakages in linux-next get resolved by
BROKEN? I know Stephen is capable of fixing various compilation problems
by himself and given the whole-tree scope it's heroic efforts, leaving
the shortcuts for the rest. In this case the fix may not be obvious so
I'd understand not merging my for-next branch at all or merging a stub
like the latest rc instead, ie. resolving that on the integration level
and not touching the config or code itself.