		Maintainers And Source Submission Procedures

	In order to keep things easy for the maintainers please try to
follow the guidelines given. Not all of these guidelines matter for every
trivial 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 and 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 thats the only way you will find things
like the fact version 3 firmware needs a magic fix you didnt 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.

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 actual needs to
become a generalised kernel feature ready for next time.
	PLEASE try and 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 doesnt work for everything or
does something very odd once a month document it.

6.	Make sure you have the right to send any changes you make. If you
do changes at work you may find your employer owns the patch not you.

7.	Happy hacking


[This file is new: I've just put the existing network contacts in, other
 people please add yourselves] -- AC

		-----------------------------------

Maintainers List (try to look for most precise areas first)

P: Person
M: Mail patches to
L: Mailing list that is relevant to this area
S: Status
	Supported:	Someone is actually paid to look after this (wildly
			improbable).
	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 driver].
	Obsolete:	Ex code. Something tagged obsolete generally means
			its been replaced by a better system and you should
			be using that.

3C501 NETWORK DRIVER
P:	Alan Cox
M:	net-patches@lxorguk.ukuu.org.uk
L:	linux-net@vger.rutgers.edu
S:	Maintained

APPLETALK NETWORK LAYER
P:	Alan Cox & University Of Michigan
M:	net-patches@lxorguk.ukuu.org.uk, Cc: netatalk@umich.edu
L:	[Someone fill in the netatalk list here]
S:	Maintained

AX.25 NETWORK LAYER
P:	Jon Naylor
M:	jsn@cs.nott.ac.uk
L:	linux-hams@vger.rutges.edu
S:	Maintained

IPX NETWORK LAYER
P:	Alan Cox [for the moment]
M:	net-patches@lxorguk.ukuu.org.uk
L:	linux-ipx@vger.rutgers.edu [will change]
S:	Maintained

NETROM NETWORK LAYER
P:	Jon Naylor
M:	jsn@cs.nott.ac.uk
L:	linux-hams@vger.rutges.edu
S:	Maintained

NETWORKING [GENERAL]:
P:	Alan Cox
M:	net-patches@lxorguk.ukuu.org.uk
L:	linux-net@vger.rutgers.edu
S:	Odd Fixes <-> Maintained subject to workloads

SMP:
P:	Alan Cox
M:	smp-patches@lxorguk.ukuu.org.uk
L:	linux-smp@vger.rutgers.edu
S:	Maintained

REST:
P:	Linus Torvalds
S:	Buried alive in email
