Re: Process for doing early internal type review on the list

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

Arg, fix Kiryl's email address.

On Wed, 2026-08-26 at 16:59 -0700, Rick Edgecombe wrote:
> Sean has long been pushing TDX developers to review less internally and capture
> everything on the list. For several reasons:
>  - Avoid thrash by hashing out things internally that are just overturned later.
>  - Capture all the design decisions in lore history.
>  - Help developers grow by getting comfortable working and making mistakes in   
>    public.
>  - A strong personal conviction that through some confluence of intangibles,
>    working in public produces better outcomes for the kernel?
> 
> At this point we pretty much do all TDX KVM patch review externally. But there
> were a couple straggling cases we ran into recently where not working in public
> produced snags:
> 1. Far out things that are in POC stages (e.g. DICE, and next migration)
> 2. Things that are held internally to not overwhelm the list with too much TDX
> stuff at once, while also continuing to make some progress on them. (TDX huge
> pages)
> 
> In an off-list discussion, the idea came up to have something like RFC, but to
> denote that the posting was for early "get it ready" type review. That it was
> being shared only to capture discussion, but not garner attention. It could be
> used for these straggling categories to do the review in public, but just off to
> the side. It would be an optional thing instead of internal review. Not
> required, just encouraged when possible. That kind of idea.
> 
> 
> Sean suggested a "FUTURE" tag like "[PATCH FUTURE]". He didn't like "PREP"
> because it could be confused for a patch that was preparatory for another patch.
> I don't love FUTURE because is time focused, rather than about the purpose of
> sending the patches. How about "PREVIEW"?
> 
> Dave, I'm wondering if you would want to have a similar process for tip targeted
> TDX series?
> 
> Thanks,
> 
> Rick