Re: [PATCH v2 0/3] rust: add `bitfield!` macro

Mark Brown
2026-04-17T11:00:04Z

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

On Fri, Apr 17, 2026 at 07:55:57AM +0200, Miguel Ojeda wrote:
> On Fri, Apr 17, 2026 at 12:19 AM Danilo Krummrich <dakr@kernel.org> wrote:

> > So, in order to not motivate workarounds, starting from the next cycle, the
> > drm-rust-next branch will be open for new features at all times.

> > Consequently, all patches applied to drm-rust-next after -rc6 do not target the
> > upcoming merge window, but the next one.

> I think that for branches going into linux-next, in general, new
> material is not meant to be added until the merge window closes, e.g.
> from last -next:

> The merge window is open, so please to not addd any v7.1 material
> to your linux-next included branches until after the merge window closes.

> Some things do target future merge windows (e.g. Rust itself was such
> a case for a long time), so it may be fine when adding it before the
> merge window opens, but I think the idea is mostly to avoid too much
> movement during the merge window to avoid interfering with other
> maintainers finishing their trees for Linus etc.

> But not sure how flexible this is -- Cc'ing Mark.

Yes, the idea is that at the end of the merge window -next should only
have a few fixes in it since everything should've been sent to Linus.
This also applies to things being added after you've sent your pulls to
the DRM core maintainers, if something isn't going to go in during the
merge window you shouldn't be adding it to -next.

For the most part nobody's actually checking that other than the reports
I send to Linus highlighting which trees have the most commits in -next
so if you're not disruptive the chances are nobody will notice but you
shouldn't do it. As Miguel says it's trying to avoid causing issues for
other people, plus the general concept of -next is that it's covering
what's currently scheduled to go into Linus' tree.

Of course, nothing stops you maintaining a branch which isn't in -next
and is open all the time and that won't have any wider impact.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]