List of maintainers and how to submit kernel changesPlease try to follow the guidelines below. This will make thingseasier on the maintainers. Not all of these guidelines matter for everytrivial patch so apply some common sense.1. Always _test_ your changes, however small, on at least 4 or 5 people, preferably many more.2. Try to release a few ALPHA test versions to the net. Announce them onto the kernel channel and await results. This is especially important for device drivers, because often that's the only way you will find things like the fact version 3 firmware needs a magic fix you didn't know about, or some clown changed the chips on a board and not its name. (Don't laugh! Look at the SMC etherpower for that.)3. Make sure your changes compile correctly in multiple configurations. In particular check that changes work both as a module and built into the kernel.4. When you are happy with a change make it generally available for testing and await feedback.5. Make a patch available to the relevant maintainer in the list. Use 'diff -u' to make the patch easy to merge. Be prepared to get your changes sent back with seemingly silly requests about formatting and variable names. These aren't as silly as they seem. One job the maintainers (and especially Linus) do is to keep things looking the same. Sometimes this means that the clever hack in your driver to get around a problem actually needs to become a generalized kernel feature ready for next time. See Documentation/CodingStyle for guidance here. PLEASE try to include any credit lines you want added with the patch. It avoids people being missed off by mistake and makes it easier to know who wants adding and who doesn't. PLEASE document known bugs. If it doesn't work for everything or does something very odd once a month document it.

PLEASE remember that submissions must be made under the terms of the OSDL certificate of contribution (http://www.osdl.org/newsroom/press_releases/2004/2004_05_24_dco.html) and should include a Signed-off-by: line.

-----------------------------------Maintainers List (try to look for most precise areas first)Note: For the hard of thinking, this list is meant to remain in alphabeticalorder. If you could add yourselves to it in alphabetical order that would beso much easier [Ed]P: PersonM: Mail patches toL: Mailing list that is relevant to this areaW: Web-page with status/info

S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. Odd Fixes: It has a maintainer but they don't have time to do much other than throw the odd patch in. See below.. Orphan: No current maintainer [but maybe you could take the role as you write your new code]. Obsolete: Old code. Something tagged obsolete generally means it has been replaced by a better system and you should be using that.3C359 NETWORK DRIVERP: Mike PhillipsM: mikep@linuxtr.net