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

[Alexandre Courbot]

On Fri Apr 17, 2026 at 10:33 AM JST, Alexandre Courbot wrote:
> On Fri Apr 17, 2026 at 7:18 AM JST, Danilo Krummrich wrote:
>> On Thu Apr 16, 2026 at 1:22 AM CEST, John Hubbard wrote:
>>> Can we please put this into your drm-rust-next-staging ASAP? I don't
>>> think we have any comments that would really need to hold that up.
>>
>> I would like to see the first patch being split up and we also need to agree the
>> merge strategy for this series and obtain the corresponding ACKs first.
>>
>> That said, I'm not a huge fan of the drm-rust-next-staging thing. It started out
>> as part of Alex' (private) process of staging patches he's about to pick up
>> (which is fine of course).
>
> Yeah, if we added this patch it would then become a mix of "things to
> push when drm-rust-next" reopens, and "things NVIDIA depends on but are
> not ready yet". For the record I was a bit slow to reply but would have
> suggested carrying this patch outside of `drm-rust-next-staging` to not
> mix things up.
>
>>
>> But now it seems to develop into some semi-official "shadow infrastructure" for
>> when the drm-rust tree is closed after -rc6 and during the merge window, and
>> it's not part of the official drm-rust workflow and other maintainers don't have
>> oversight of it.
>>
>> 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.
>
> If that doesn't add any burden to you and Alice, then I think that's a
> definitely an improvement to our process.

Actually thinking more about this, this might not be the improvement I
expected at first.

Take for instance the current time of the merge window: both `rust-next`
and `drm-rust-next` have been merged into `master`, which provides us an
ideal base for sending patches that will target `-rc1`.

But if we keep submitting to the pre-merge `drm-rust-next`, then we are
in a situation where the extra patches sent to `drm-rust-next` need to
be rebased when `-rc1` is released, with a clear potential for
conflicts.

So at the end of the day, it would still be cleaner to use `master` in
prevision of the `-rc1` tagging and we would be in more or less the same
situation as today. `drm-rust-next-staging` is currently based on
`master`.

I guess the problem is that my internal process has leaked a bit, when
it is really intended to be a temporary convenience (both for me and for
NVIDIA contributors) and something drm-rust maintainers can completely
ignore.