Deeper problems in the Linux kernel

What I'm reading in all this thread is a huge confusion between "maintaining" and "developing". It's basically said "the work's already done blablabla". No. That's the development part. The maintenance part *starts* once the code gets merged and *ends* for developers. Maintaining means:
- reading unqualified bug reports that possibly look like they might be related to what you're working on, and scratch one's head to try to guess if that could be related or not.
- helping reporters get more traces, debug info, run tests, patches etc to try to better figure the problem
- write fixes and test them or get them tested
- deal with backports (a nightmare in some API changes, especially when patches apply and build fine while you know the API differs)
- deal with security reports, in particular the mighty ones where you're supposed to be discrete and not request everyone's help since you're a maintainer and you know.
- and all that most often alone before others have a look, or even against those who initially say "it's probably something over there".

It's simply not a matter of sending a write-only code piece to someone and considering the job done over the week-end, it's a permanent, hard work. And the worst of this is that the maintainer's job is one of those that are the hardest to scale, because it's not just based on time and skills, it's based on experience. You can decide to have as many co-maintainers as you want, if you have 30 years of experience, it will take 30 years for a new one to be able to replace you with the same level of expertise, judgement and autonomy.

*That* is the problem.

I know Christoph can easily have harsh words, and I don't know the level of complexity of the proposed changes, but I know that as a maintainer of another software, it often happens to me to have to say "no" to some changes because I figure they will get us into hell, without the person in front of me being able to understand why, by lack of experience on that matter. So in this case, I have to sit down with the person and work for a few days to try to redesign their change with them in order to reach a point where nobody is able to envision a future major problem anymore (that doesn't mean there will be none, just that the maximum chances will have been put on our side). And it even happens with other highly skilled developers and maintainers for whom I have a lot of respect, just like some of them sometimes reject my changes for the same reasons. Keep in mind that every time an issue pops up, the first ones that are questioned are those who know the bits and bytes at the lowest levels and know how to read a backtrace, an hex dump or a network trace, and the vast majority of the time in the end it's not for them, it only allows to know whom to route it to.

The issue we're often reading here is "these bastards are rejecting our stuff, let's replace them". But it *exactly* illustrates the lack of maturity and experience needed to gauge the impacts of certain changes for existing maintainers. And there are areas that are trickier than others, just like there are maintainers who have more elasticity than other ones to adopt new technologies, and that's fine. But as a general rule-of-thumb, if you have not been forced to maintain an API you've designed for 10+ years regretting some early mistakes every single day you touch it, you just have no idea what a maintainers' difficulties are and you cannot qualify to judge their job nor their judgement, essentially based on intuition and recognized patterns.

It's certain that the form could be better. Christoph is known for not taking gloves. Others might just simply feel overwhelmed and decide to silently resign because they don't see themselves with a extra level of complexity. Others might just think "let's see, and I might give up later if/when it becomes too hard". Others might feel more at ease with estimating how to address shortcomings or might even try to themselves take part of the change. Nobody's equal and it takes of everyone to get a collective expertise as there is on Linux. Let's just not trivially dismiss the difficulties some may face in front of a task they did not decide to receive.