On Tue, Jul 9, 2024 at 2:18 PM Daniel P. Berrangé <berra...@redhat.com> wrote: > My thought is that the initial merge focuses only on the build system > integration. So that's basically patches 1 + 2 in this series. > > Patch 3, the high level APIs is where I see most of the work and > collaboration being needed, but that doesn't need to be rushed into > the first merge. We would have a "rust" subsystem + maintainer who > would presumably have a staging tree, etc in the normal way we work > and collaborate
It's complicated. A "perfect" build system integration would include integration with Kconfig, but it's not simple work and it may not be Manos's preference for what to work on (or maybe it is), and it's also not a blocker for further work on patches 3-4. On the other hand, patches 3 and 4 are _almost_ ready except for requiring a very new Rust - we know how to tackle that, but again it may take some time and it's completely separate work from better build system integration. In other words, improving build system integration is harder until merge, but merge is blocked by independent work on lowering the minimum supported Rust version. This is why I liked the idea of having either a development tree to allow a merge into early 9.2. On the other hand, given the exceptional scope (completely new code that can be disabled at will) and circumstances, even a very early merge into 9.1 (disabled by default) might be better to provide developers with the easiest base for experimenting. The requirements for merging, here, would basically amount to a good roadmap and some established good habits. An merge into early 9.2 would be a bit harder for experimenting, while merging it now would sacrifice CI integration in the initial stages of the work but make cooperation easier. However, it's difficult to say what's best without knowing Manos's rationale for preferring not to have a development tree yet. Paolo
