linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: linux-next: build failure after merge of the btrfs tree
Date: Fri, 29 Oct 2021 14:14:09 +0200	[thread overview]
Message-ID: <20211029121409.GX20319@suse.cz> (raw)
In-Reply-To: <CAHp75VdXJEuY86pFC+bLoGbAYuGsA+KqEV-g4Dca25HHD-njHA@mail.gmail.com>

On Fri, Oct 29, 2021 at 01:58:53PM +0300, Andy Shevchenko wrote:
> On Friday, October 29, 2021, David Sterba <dsterba@suse.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.

  parent reply	other threads:[~2021-10-29 12:14 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-27 10:09 linux-next: build failure after merge of the btrfs tree Stephen Rothwell
2021-10-29  8:28 ` Stephen Rothwell
2021-10-29  9:52 ` David Sterba
2021-10-29 10:50   ` David Sterba
     [not found]     ` <CAHp75VdXJEuY86pFC+bLoGbAYuGsA+KqEV-g4Dca25HHD-njHA@mail.gmail.com>
2021-10-29 12:14       ` David Sterba [this message]
2021-10-31  4:30         ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2025-12-17 22:26 Stephen Rothwell
2025-12-18 12:14 ` David Sterba
2025-02-26 23:32 Stephen Rothwell
2025-02-27  9:40 ` David Sterba
2024-10-23 21:57 Stephen Rothwell
2024-10-23 22:28 ` Qu Wenruo
2024-10-24  0:47   ` David Sterba
2024-10-24  0:52     ` Qu Wenruo
2024-10-24  1:05       ` David Sterba
2024-10-24  1:00     ` Stephen Rothwell
2024-10-27 22:03 ` Stephen Rothwell
2024-10-29 16:21   ` David Sterba
2023-01-12 23:36 Stephen Rothwell
2023-01-13 10:59 ` David Sterba
2022-11-07 22:42 Stephen Rothwell
2022-11-08 11:21 ` David Sterba
2022-09-06 19:44 Stephen Rothwell
2022-08-21 23:44 Stephen Rothwell
2021-10-08  4:03 Stephen Rothwell
2021-10-08  5:56 ` Qu Wenruo
2020-04-21  0:25 Stephen Rothwell
2020-04-21  0:40 ` Qu Wenruo
2020-04-21  1:13   ` Stephen Rothwell
2020-04-21  1:33     ` Qu Wenruo
2020-04-21  1:55       ` Stephen Rothwell
2020-04-22 21:29 ` David Sterba
2020-04-24  5:17   ` Qu Wenruo
2020-02-19 22:23 Stephen Rothwell
2020-02-21 11:30 ` David Sterba
2020-02-21 11:33   ` David Sterba
2015-08-21  0:42 Stephen Rothwell
2012-12-16 23:00 Stephen Rothwell
2012-12-17  0:15 ` Chris Mason
2012-12-17  2:52   ` Chris Mason
2012-12-17  3:13     ` Stephen Rothwell
2012-12-17  3:38       ` Chris Mason
2012-12-17  2:01 ` Chris Mason
2012-10-01  4:22 Stephen Rothwell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211029121409.GX20319@suse.cz \
    --to=dsterba@suse.cz \
    --cc=akpm@linux-foundation.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).