Many of them have, in fact, done all of those things, and have done them over a time horizon measured in years. Many of the R4L developers are paid by their employers specifically to work on R4L and can therefore be considered reasonably reliable and not drive-by contributors.
Many existing maintainers are not "general contributors"
It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.
Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.
I disagree. If you want to provide technical leadership by massively changing the organization and tooling of a huge project that has been around a long time, it should be absolutely mandatory to spend years building trust and doing work that you don't want to do.
That's just how programming on teams and trust and teamwork actually works in the real world. Especially on a deadly serious not-hobby project like the kernel.
Sometimes you are gonna have to do work that doesn't excite you. That's life doing professional programming.
Everything Ted Tso recommended is just common sense teamwork 101 stuff and it's just generally good advice for programmers in their careers. The inability of rust people to follow it will only hurt them and doom their desire to be accepted by larger more important projects in the long run. Programming on a team is a social affair and pretending you don't have to play by the rules because you have such great technical leadership is arrogant.
> It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.
It is absolutely reasonable if the work they want to do is to refactor the entire project.
Many existing maintainers are not "general contributors"
It is unreasonable (and a recipe for long-term project failure) to expect every new contributor to spend years doing work they don't want to do (and are not paid to do) before trusting them to work on the things they do want (and are paid) to do.
Christoph refused to take onboard a new maintainer. The fight from last August was about subsystem devs refusing to document the precise semantics of their C APIs. These are signs of fief-building that would be equally dangerous to the long-term health of the project if Rust was not involved whatsoever.