Proposal to move Rust std work to edk2-staging

Proposal to move Rust std work to edk2-staging

[Ayush Singh]

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

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

[Michael Kubacki]

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