|
Top-level
@lina I have seen the same situation in fs realms too, some "not-so-polite" MM guys want to improve their work and pushing new interfaces to fses. But the main objective of the maintainer for any fs, is to keep their fs working without regression. So migrating to newer interface is not the priority and will only happen gradually. 5 comments
 @mawei You're completely misunderstanding what I tried to do... I just tried to fix what arguably are bugs in drm_sched, which didn't change the API at all, they only made it reasonable to use by turning some usages from a crash to handled gracefully. And the maintainer rejected that. Because the only driver he cares about doesn't run into this issue, so he thinks it shouldn't be fixed. @mawei It wasn't even BUG_ON, it would outright crash and oops... the maintainer said I was using the API wrong, but enforcing using it "right" by his definition without fixing this would require reimplementing half the logic in the scheduler outside of it just to duplicate its functionality enough to track and avoid the problem case. It's nuts. The problem could be easily fixed within the scheduler, it was just a non-intrusive change to one function to correctly handle a particular case. |
Gregory's Server
@lina To me, as long as the discussions are still kept constructive, (not some BS like "yeah, this feature is already implemented in XXX several years ago and it's all your fs' fault not to do it", or "XXXfs is definitely better than YYYYfs") some delay of merging is totally acceptable, and if one really needs to fix others' bugs, that's just bonus patches to me.
It may looks frustrating for now to fix both rust and C, but aren't more contribution better?