On Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain <mcgrof@xxxxxxxxxx> wrote: > > The rationale here is that a rust binding means commitment then also > from fresh blood to help co-maintain review C / Rust for exising code > when there is will / desire to collaborate from an existing C maintainer. > > I realize this may be a lot to ask, but I think this is one of the > responsible ways to ask to scale here. Yeah, there have been different approaches for this taken by different subsystems -- it depends on their constraints and how much the submitter can commit to. For instance, some maintainers may want to keep being the maintainers of both Rust and C. Some want that the submitter becomes a new co-maintainer in the subsystem and eventually maintainers both C and Rust. Some prefer to have a new maintainer for the Rust side only, i.e. considering Rust as a new section of the subsystem with a new `MAINTAINERS` entry and all. On top of that, some allow the C and Rust sides to be independent, to the point of allowing temporary breakage on the Rust side if the new maintainers commits to be quick fixing it (though I have my reservations about how well that would eventually work if more core/common subsystems start doing that -- linux-next could be broken a lot of the time for the Rust side). But, yes, I think Rust is a great opportunity to get new co-maintainers, as well as getting new developers involved with kernel maintenance in general, which could help with other issues too. Cheers, Miguel
