Re: [GIT PULL] bcachefs fixes for 6.11-rc6

[Kent Overstreet]

On Tue, Sep 03, 2024 at 03:53:56PM GMT, Geert Uytterhoeven wrote:
> Hi Kent,
> 
> Replying here, as there is (again) no patch email to reply to to report issues.
> 
> noreply@xxxxxxxxxxxxxx is reporting several build failures[1] in linux-next:
> 
>     fs/bcachefs/sb-members.c: In function ‘bch2_sb_member_alloc’:
>     fs/bcachefs/sb-members.c:503:2: error: a label can only be part of
> a statement and a declaration is not a statement
>       503 |  unsigned nr_devices = max_t(unsigned, dev_idx + 1,
> c->sb.nr_devices);
>           |  ^~~~~~~~
>     fs/bcachefs/sb-members.c:505:2: error: expected expression before ‘struct’
>       505 |  struct bch_sb_field_members_v2 *mi =
> bch2_sb_field_get(c->disk_sb.sb, members_v2);
>           |  ^~~~~~
> 
> Apparently this fails with gcc-10 and older, but builds with gcc-11
> and gcc-12.

Thanks for the report - it's fixed now (thanks, Hongbo)

> The failure is due to commit 4e7795eda4459bf3 ("bcachefs:
> bch2_sb_member_alloc()"), which is nowhere to be found on
> lore.kernel.org.  Please stop committing private unreviewed patches
> to linux-next, as several people have asked before.

They're still in git; I'd suggest just doing a git send-email and
tweaking the output if you want to start a review on a patch you find.

There's been some discussions in filesystem land about how/when we want
patches to hit the list - I'm not a huge fan of the patch bombs that
drown everything else out on the list, which is what it would be if I
did mail everything.

But if the email workflow is really what you want, and if it's going to
be generating useful review (list activity is growing...), I could be
convinced...

We're getting past the "just fix all the stupid shit" phase, and my
output is (I hope) trending toward something more stustainable, with a
stream of more _interesting_ patches to talk about, so - yeah, it's
starting to sound more reasonable, if that's what people want.

My priority is just going to be on fostering _useful_ technical
discussion. If the only reason you're wanting patches on the list is
because of trivial shit automated tests can and do catch - that's not a
win, to me. If I start posting patch series and we seem to be learning
from it, I'll stick with it.