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

["Alexandre Courbot" <acourbot@nvidia.com>]

On Fri Apr 17, 2026 at 12:19 PM JST, John Hubbard wrote:
> On 4/16/26 8:11 PM, Alexandre Courbot wrote:
>> 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.
> ...
>>>> 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.
>
> Yes, some conflicts, but probably not too bad, due to the much
> newer base, right?

Most of the time, hopefully. But that's still labor shifted from us (as
I would address the conflicts before merging the patches) to the
drm-rust maintainers.

>
>> 
>> 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.
>
> The only reason that it leaked is because there was an underlying unmet
> need, to begin with, which is: how to continue developing on some
> "appropriate" branch during two weeks (20% of the year) when our main
> branch is locked down and stale?

It's actually 4 weeks (from -rc6 to release, plus 2 weeks until -rc1).

I agree it would be nice to improve the situation - I'm just not sure
that keeping drm-rust-next open is the optimal solution here.