	List of maintainers and how to submit distro changes

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.

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.

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 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.

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.


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

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
W: Web-page with status/info
S: Status, one of the following:

	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 code].
	Obsolete:	Old code. Something tagged obsolete generally means
			it has been replaced by a better system and you
			should be using that.

UCLINUX/DISTRIBUTION
P:	Greg Ungerer
M:	gerg@uclinux.org
M:	gerg@snapgear.com
L:	uclinux-dev@uclinux.org
S:	Maintained

UCLINUX LINUX WITHOUT MMU SUPPORT
P:	D. Jeff Dionne
M:	jeff@uclinux.org
M:	jeff@arcturusnetworks.com
L:	uclinux-dev@uclinux.org
W:	http://www.uclinux.org
S:	Maintained 

UCLINUX/COLDFIRE
P:	Greg Ungerer
M:	gerg@snapgear.com
P:	David McCullough
M:	davidm@snapgear.com
W:	http://www.uclinux.org/ports/coldfire
S:	Maintained

UCLINUX FOR DRAGONBALL
P:      Michael Leslie
M:      mleslie@lineo.ca
P:      Randy Buchanan
M:      randyb@lineo.com
W:      http://www.uclinux.org/ports
S:      Maintained

