On Tue, Jul 9, 2024 at 9:38 AM Manos Pitsidianakis <manos.pitsidiana...@linaro.org> wrote: > Ah, alright. That wasn't obvious because that e-mail was not directed > to me nor did it mention my name :)
Oh, ok. Sorry about that. Generally when I say "we" I include as large a part of the community as applicable. > I do not want to do that, in any case. I do not think it's the right approach. No problem with that (and in fact I agree, as I'd prefer a speedy merge and doing the work on the QEMU master branch); however, we need to reach an agreement on that and everybody (including Daniel) needs to explain the reason for their position. Daniel's proposed criteria for merging include: - CI integration - CI passing for all supported targets (thus lowering the MSRV to 1.63.0) - plus any the code changes that were or will be requested during review That seems to be a pretty high amount of work, and until it's done everyone else is unable to contribute, not even in directions orthogonal to the above (cross compilation support, less unsafe code, porting more devices). So something has to give: either we decide for an early merge, where the code is marked as experimental and disabled by default. Personally I think it's fine, the contingency plan is simply to "git rm -rf rust/". Or we can keep the above stringent requirements for merging, but then I don't see it as a one-person job. If I can say so, developing on a branch would also be a useful warm-up for you in the maintainer role, if we expect that there will be significant community contributions to Rust. Paolo
