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

[John Hubbard <jhubbard@nvidia.com>]

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?

> 
> 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?

There is a real need to do something.


thanks,
-- 
John Hubbard