patch-1.3.97 linux/MAINTAINERS

• Lines: 95
• Date: Mon Apr 29 07:23:09 1996
• Orig file: v1.3.96/linux/MAINTAINERS
• Orig date: Tue Apr 23 13:57:01 1996

diff -u --recursive --new-file v1.3.96/linux/MAINTAINERS linux/MAINTAINERS
@@ -1,41 +1,47 @@
-		Maintainers And Source Submission Procedures
+	List of maintainers and how to submit kernel changes
 
-	In order to keep things easy for the maintainers please try to
-follow the guidelines given. Not all of these guidelines matter for every
+Please try to follow the guidelines below.  This will make things
+easier on the maintainers.  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.
+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 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).
+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 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.
+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. 
+	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.
+	'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 doesn't work for everything or
-does something very odd once a month document it.
+	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.
 
 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.
+	do changes at work you may find your employer owns the patch
+	not you.
 
-7.	Happy hacking
+7.	Happy hacking.
 
 
 [This file is new: I've just put the existing network contacts in, other
@@ -49,7 +55,8 @@
 M: Mail patches to
 L: Mailing list that is relevant to this area
 W: Web-page with status/info
-S: Status
+S: Status, one of the following:
+
 	Supported:	Someone is actually paid to look after this (wildly
 			improbable).
 	Maintained:	Someone actually looks after it.
@@ -57,9 +64,10 @@
 			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:	Ex code. Something tagged obsolete generally means
+	Obsolete:	Old 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