As an outside observer, literally no skin in this game, I can see his point. If his C code changes breaks other C code then he is at an advantage compared to if his C code breaks a Rust binding or Rust drivers. The degree to which this adds to his burden of maintenance is up to him to decide.
As for less work, that is alternative two from my original post which states the maintainer now has to wait for someone else to do the work or risk his change being stalled (worse case: indefinitely). It doesn't matter if the R4L team promises that they are OK with broken Rust code since the only person whose decision matters is Linus. Until Linus clarifies his stance on broken Rust builds the promises of the R4L team are promises that they are literally incapable of delivering on.
> he will still be contacted for information regarding these things.
Just like any other user, and he is free to ignore them just like any other person doing so.
There’s 2 kinds of scenarios here:
- Rust code involved: C code change breaks Rust. ~Send~ ~an~ ~email~ ~and~ move on.
- C code involved: inform other C devs, either work with them or wait for them to fix.
The way I see it, either way, the “Rust stuff adds unacceptable amounts of workload” doesn’t really check out.
Edit: turns out he doesn’t even need to inform the Rust devs.
This isn’t blocking any drivers. Just adds duplicate code.