Re: [edk2-devel] Proposal to move Rust std work to edk2-staging

["Michael Kubacki" <mikuback@linux.microsoft.com>]

Hi Ayush,

For the purposes of this work, please don't let process impede progress. 
The main purpose of moving to edk2-staging is to broaden exposure of the 
work and encourage additional collaboration. In particular, within the 
Tianocore/edk2 community.

As the author, you can choose how to best present your work to the 
communities - Rust and Tianocore.

I think it's reasonable to keep the edk2-staging repo light with 
documentation, examples, and edk2-specific changes that reference the 
Rust changes in your rust-lang/rust fork. The code in the edk2-staging 
repo should ultimately aim to transition to an edk2 PR as the edk2 
contribution from the project.

Regards,
Michael

On 7/30/2022 6:01 AM, Ayush Singh wrote:
> Hello everyone. The work on Rust std for UEFI has been progressing 
> smoothly. Running Rust tests is now possible in it's entirety. The 
> number of tests that fail is 133 (4 cause exception + 129 normal fails) 
> out of 13,212 tests. Apart from the 4 tests that cause exceptions, most 
> of the 129 other tests can be ignored since they are caused by needing 
> dynamic linking and/or stack unwinding. So I think, it is time to start 
> considering moving the project to a more appropriate repository before I 
> open a PR upstream.
> 
> 
> However, I do have some concerns regarding moving to edk2-staging:
> 
> 1. Rust development workflow does not use Mailing lists and Patches. 
> This might create friction for the purely `rustc` developers who might 
> want to submit changes and are accustomed to PRs.
> 
> 2. Rust project does not seem to care about maintaining a clean history 
> (most of the merges are performed by bots in form of roll-up merges). 
> This is much different from how edk2 projects are usually managed. The 
> reason where this becomes a problem is having to do re-bases. While Rust 
> provides strong guarantees for stability of user facing APIs, the 
> internal std APIs are constantly changing. Combine that with no 
> clean-history and the upstream PR will probably have to be re-based on 
> latest master every few weeks (and it will likely need manual 
> intervention).
> 
> 
> I am planning on getting the code base ready for upstream PR before 15th 
> August. The main things left to do is to publish new versions of 
> `compiler_builtins` and `r-efi` crates, and refactor the code and UEFI 
> documentation.
> 
> 
> Yours Sincerely
> 
> Ayush Singh
> 
> 
> 
> 
>