Jens, > Additionally, it would seem saner to standardize rules around when > code is expected to hit the maintainers hands for kernel > releases. Both yours and Martins deals with that, there really > shouldn't be the need to have this specified in detail per sub-system. Yeah. There is basically nothing specific about SCSI in my write-up outside of the branch naming. I deliberately didn't mention coding style preferences. We have so much 20+ year old cruft in SCSI that's impossible to even entertain. But I do request new code to follow coding-style.rst. BYOXT. Also note that the original target audience for my document. It was aimed at onboarding new driver contributors from hardware companies. So people that don't live and breathe Linux development and who are not intimately familiar with the kernel development process. It's possible that we have this information in Documentation/ these days; I'll go look. But it didn't exist when this doc was written. And in my experience nobody coming to Linux development from the outside understands what the "merge window" is. And when the appropriate time is to submit patches and features. I think this would be a great area to have a common set of guidelines and documentation. I'd prefer for this to be global and then let maintainers apply their own wiggle room instead of documenting particular rules for a given subsystem. One pet peeve I have is that people are pretty bad at indicating the intended target tree. I often ask for it in private mail but the practice doesn't seem to stick. I spend a ton of time guessing whether a patch is a fix for a new feature in the x+1 queue or a fix for the current release. It is not always obvious. -- Martin K. Petersen Oracle Linux Engineering
