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

["Danilo Krummrich" <dakr@kernel.org>]

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