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

Danilo Krummrich
2026-04-17T12:00:41Z

On Fri Apr 17, 2026 at 7:55 AM CEST, Miguel Ojeda wrote:
> 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.

This all builds on the assumption that we don't have a process in place that
covers this.

However, all major DRM trees run the above process and handle linux-next in the
following way.

* -next
Features; open at all times.

* -next-fixes
Fixes for features in -next that have been included before -rc6; active
between -rc6 and the next -rc1.

* -fixes
Fixes targeting the current -rc cycle.

These are mapped to two additional branches that linux-next pulls from:

* for-linux-next
Normally points to -next. Between -rc6 and -rc1 it switches to
-next-fixes instead.

* for-linux-next-fixes
Always points to -fixes.

The same thing is going to happen for drm-rust tree, once everything is set up.

- Danilo