patch-1.3.68 linux/MAINTAINERS

• Lines: 108
• Date: Wed Feb 21 08:33:21 1996
• Orig file: v1.3.67/linux/MAINTAINERS
• Orig date: Thu Jan 1 02:00:00 1970

diff -u --recursive --new-file v1.3.67/linux/MAINTAINERS linux/MAINTAINERS
@@ -0,0 +1,107 @@
+		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