Comment by wffurr
1 day ago
From what I have read, the intent seems to be that a C maintainer can make changes that break the Rust build. It’s then up to the Rust binding maintainer to fix the Rust build, if the C maintainer does not want to deal with Rust.
The C maintainer might also take patches to the C code from the Rust maintainer if they are suitable.
This puts a lot of work on the Rust maintainers to keep the Rust build working and requires that they have sufficient testing and CI to keep on top of failures. Time will tell if that burden is sustainable.
> Time will tell if that burden is sustainable.
Most likely this burden will also change over time. Early in the experiment it makes sense to put most of the burden on the experimenters and avoid it from "infecting" the whole project.
But if the experiment is successful then it makes sense to spread the workload in the way that minimizes overall effort.
It took me a while to understand the conflict until this dawned on me. It doesn't matter how many assurances the R4L team gives that they are on the hook for keeping up with breaking changes during the experiment, some maintainers were dismissive of the project altogether, because of the project is successful, then they have to care. It wasn't until recently that we are all operating on different definitions of success. If your definition of success is "it proves that it's possible to get it working", the project succeeded ages ago, which means that you're running out of time to stop the project if you really don't want to ever have to care about it. But that's not the definition of a successful experiment, because otherwise it would already have been declared. One potential definition of success is "all of the tooling necessary is there, it's reliable, the code quality is higher than what was there before, and the number of defects in the new code is statistically lower". If that is the goal, then the time where the maintainers don't need to fix bindings as part of refractors is pushed further into the future. But that success goal also implies that everything is in place to be minimally disruptive to maintainers already.
If it were me, I would have started building the relationships now with the R4L team to "act as-if" Rust is here to stay and part of the critical path, involving them when refractors happen but without the pressure to have to wait for them before landing C changes. That way you can actually exercise the workflow and get real experience on what the pain might be, and work on improving that workflow before it becomes an issue. Arguably, that is part of the scope of the experiment!
The fear that everyone from R4L might get up and leave from one day to the next, leaving maintainers with Rust code they don't understand, is the same problem of current subsystem maintainers getting up and leaving from one day to the next leaving no-one to maintain that code. The way to protect against that is to grow the team's, have a steady pipeline of new blood (by fostering an environment that welcomes new blood and encourages them to stick around) and have copious amounts of documentation.