> > > That does not make much sense to me. In order to review the code you > > > need to understand it and if you already understand the code, you > > > can write it as well. > > > > Huh, have you ever maintained something? I couldn't write most of the > > drivers I get for I2C, because I simply don't have access to the > > hardware. > > But the lack of HW was the one thing stopping you right ? Not the > lack of skills or knowledge. Lack of time is another one. And lack of interest a third one. Unlike the casual developer, I'd like to work more on the core and infrastructure than on drivers. > I am just saying that it's quite likely > that there are even less people with the skills who are willing to be > dedicated to review than developers who are willing to review > patches from time to time. Right. And give those rare bunch some money to focus on this kind of work (opposed to stuff like board bringup) is what I am proposing. > > Then, think more of dedicated maintainers: I don't know one maintainer > > who is not interested in hacking as well. Which is needed, of course. > > There are reviews which make flaws in the subsystem core obvious. > > Usually, the original patch comitter is only interested in this reviewed > > patch and does not want to deal with the core. So, this kind of work is > > up to the maintainer. If maintainers are backed off, more of this work > > could be done IMO. > > Are you suggesting that existing maintainers should either stop > hacking, or give up maintainership in favour of those who does not > want to write code ? :) Sorry for exaggerating, but I do not think > that having people dedicated solely to review is realistic. I think we are missing each other here. Maintaining is not only reviewing but also keeping the core in shape. There is quite some hacking involved if done properly. > We should rather focus on encouraging developers to review more. That is a good, helpful thing. Yet, from my experience it won't scale enough. I'd be happy to be wrong here, though. Regards, Wolfram