Re: Rust BoF and maintainer minutes and planning the roadmap to Rust

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Sep 26, 2024 at 03:23:11PM +0100, Alex Bennée wrote:

[...]

>> One issue that came up is how we handle adequately reviewing code when
>> most of the maintainers are experienced C coders but might not know much
>> about Rust. While we want to avoid the situation of developers vetoing
>> conversion there should be communication ahead of any serious work to
>> avoid rust contributions coming out of the blue. If a maintainer feels
>> they cannot maintain a bunch of unfamiliar rust code the submitter
>> should be prepared to find people willing to become a maintainers as
>> unmaintained drive-by submissions are not useful for the long term
>> health of the project.
>
> Yep, communication is critical, if proposing to rewrite existing
> functionality. Drowning maintainers in conversion patches without
> warning is a guaranteed way to create friction between people.
>
>> With relative inexperience there was a concern we could inadvertently
>> introduce technical debt in the code base (C-like Rust vs Rusty rust).
>> What can we do to mitigate that issue?
>
> On a long enough time frame, all exiting code can be considered
> technical debt. Given the relatively sparse Rust experiance
> across our community, we're guaranteed to make more design
> mistakes in the first few years. Mitigating this is important,
> but at the same time, we should also accept we're not going
> to get everything perfect.
>
> One thing our community is very good at is obsessing about
> perfection of patch series. I can forsee us doing that to an
> even greater extent with any Rust conversions of code. If we
> are not careful we could really harm  our overall productivity
> by spending too much time striving for a perfect Rust abstraction
> first time out, even though many of us would still be relative
> newcomers to Rust, such that we don't know what we don't know.
>
> IOW, we need to be pragmatic about accepting some level of
> technical debt at times. Especially if there are cases where
> our Rust design is held back by existing C code, we might be
> better off temporarily accepting sub-optimal Rust, to avoid
> immediately refactoring piles of C code, and tackle the problems
> later.

A deliberate approach to explore some before we go all in could mitigate
the risk of taking on too much technical debt.

We obviously need to write instances of each interesting class of things
to ferret out the problems, and design good interfaces.  I'd recommend
to write few instances, ideally one, then let them mature some before we
create many more of them.  Prioritize gaining experience over quantity.

[...]