Process for doing early internal type review on the list

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

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