MAINTAINERS - coreboot - Gitiles



 	List of maintainers and how to submit coreboot 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 1 or
 	2 people, preferably many more.

 2.	Try to release a few ALPHA test versions to gerrit. Announce
 	them onto the coreboot mailing list and IRC channel and await
 	results. This is especially important on coreboot core changes,
 	but also for device drivers, because often that's the only way
 	you will find things like the fact revision 3 chipset 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!)

 3.	Make sure your changes compile correctly in multiple
 	configurations. In particular check that changes work for all
 	boards in the tree (use abuild!)

 4.	When you are happy with a change make it generally available for
 	testing in gerrit and await feedback.

 5.	Make your patch available through coreboot's gerrit code review
 	system, and add the relevant maintainer from this list as a code
 	reviewer. 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 do is to keep
 	things looking the same.  Sometimes this means that the clever
 	hack in your mainboard or chipset to get around a problem actually
 	needs to become a generalized coreboot feature ready for next time.

 	PLEASE check your patch with the automated style checker
 	(util/lint/checkpatch.pl) to catch trival style violations.
 	See http://coreboot.org/Coding_Style for guidance here.

 	PLEASE add the maintainers that are generated by
 	util/scripts/get_maintainer.pl as reviewers.  The results returned
 	by the script will be best if you have git installed and are
 	making your changes in a branch derived from coreboot.org's latest
 	git tree.

 	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 and should include a
 	Signed-off-by: line.  The current version of this "Developer's
 	Certificate of Origin" (DCO) is listed at
 	http://coreboot.org/Development_Guidelines#Sign-off_Procedure.

 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.

 Descriptions of section entries:

 	M: Maintainer: FullName <address@domain>
 	R: Designated reviewer: FullName <address@domain>
 	   These reviewers should be CCed on patches.
 	L: Mailing list that is relevant to this area
 	W: Web-page with status/info
 	Q: Patchwork web based patch tracking system site
 	T: SCM tree type and location.
 	   Type is one of: git, hg, quilt, stgit, topgit
 	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.
 	F: Files and directories with wildcard patterns.
 	   A trailing slash includes all files and subdirectory files.
 	   F:	drivers/net/	all files in and below drivers/net
 	   F:	drivers/net/*	all files in drivers/net, but not below
 	   F:	*/net/*		all files in "any top level directory"/net
 	   One pattern per line.  Multiple F: lines acceptable.
 	N: Files and directories with regex patterns.
 	   N:	[^a-z]tegra	all files whose path contains the word tegra
 	   One pattern per line.  Multiple N: lines acceptable.
 	   scripts/get_maintainer.pl has different behavior for files that
 	   match F: pattern and matches of N: patterns.  By default,
 	   get_maintainer will not look at git log history when an F: pattern
 	   match occurs.  When an N: match occurs, git log history is used
 	   to also notify the people that have git commit signatures.
 	X: Files and directories that are NOT maintained, same rules as F:
 	   Files exclusions are tested before file matches.
 	   Can be useful for excluding a specific subdirectory, for instance:
 	   F:	net/
 	   X:	net/ipv6/
 	   matches all files in and below net excluding net/ipv6/
 	K: Keyword perl extended regex pattern to match content in a
 	   patch or file.  For instance:
 	   K: of_get_profile
 	      matches patches or files that contain "of_get_profile"
 	   K: \b(printk|pr_(info|err))\b
 	      matches patches or files that contain one or more of the words
 	      printk, pr_info or pr_err
 	   One regex pattern per line.  Multiple K: lines acceptable.

 Note: For the hard of thinking, this list is meant to remain in alphabetical
 order. If you could add yourselves to it in alphabetical order that would be
 so much easier [Ed]

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

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

 RISC-V ARCHITECTURE
 M:	Ronald Minnich <rminnich@gmail.com>
 S:	Maintained
 F:	src/arch/riscv/
 F:	src/mainboard/emulation/qemu-riscv/

 GOOGLE PANTHER MAINBOARD
 M:	Stefan Reinauer <stefan.reinauer@coreboot.org>
 S:	Supported
 F:	src/mainboard/google/panther/

 INTEL MINNOWBOARD MAX MAINBOARD
 M:	Martin Roth <gaumless@gmail.com>
 S:	Maintained
 F:	src/mainboard/intel/minnowmax/

 INTEL FSP BAYTRAIL CHIP
 M:	Martin Roth <gaumless@gmail.com>
 S:	Odd Fixes
 F:	src/soc/intel/fsp_baytrail/

 INTEL FSP 1.0
 M:	Martin Roth <gaumless@gmail.com>
 S:	Odd Fixes
 F:	src/drivers/intel/fsp1_0/
 F:	src/vendorcode/intel/fsp1_0/

 ATI MACH64 Driver
 S:	Orphan
 F:	drivers/ati/mach64/

 LINT SCRIPTS
 M:	Patrick Georgi <patrick@georgi-clan.de>
 S:	Supported
 F:	util/lint/

 BUILD SYSTEM
 M:	Patrick Georgi <patrick@georgi-clan.de>
 M:	Martin Roth <gaumless@gmail.com>
 S:	Supported
 F:	Makefile
 F:	*.inc
 F:	util/kconfig/
 F:	util/sconfig/

 THE REST
 M:	Stefan Reinauer <stefan.reinauer@coreboot.org>
 L:	coreboot@coreboot.org
 T:	git http://review.coreboot.org/coreboot
 S:	Buried alive in mainboards
 F:	*
 F:	*/


	List of maintainers and how to submit coreboot 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 1 or
	2 people, preferably many more.

	2. Try to release a few ALPHA test versions to gerrit. Announce
	them onto the coreboot mailing list and IRC channel and await
	results. This is especially important on coreboot core changes,
	but also for device drivers, because often that's the only way
	you will find things like the fact revision 3 chipset 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!)

	3. Make sure your changes compile correctly in multiple
	configurations. In particular check that changes work for all
	boards in the tree (use abuild!)

	4. When you are happy with a change make it generally available for
	testing in gerrit and await feedback.

	5. Make your patch available through coreboot's gerrit code review
	system, and add the relevant maintainer from this list as a code
	reviewer. 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 do is to keep
	things looking the same. Sometimes this means that the clever
	hack in your mainboard or chipset to get around a problem actually
	needs to become a generalized coreboot feature ready for next time.

	PLEASE check your patch with the automated style checker
	(util/lint/checkpatch.pl) to catch trival style violations.
	See http://coreboot.org/Coding_Style for guidance here.

	PLEASE add the maintainers that are generated by
	util/scripts/get_maintainer.pl as reviewers. The results returned
	by the script will be best if you have git installed and are
	making your changes in a branch derived from coreboot.org's latest
	git tree.

	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 and should include a
	Signed-off-by: line. The current version of this "Developer's
	Certificate of Origin" (DCO) is listed at
	http://coreboot.org/Development_Guidelines#Sign-off_Procedure.

	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.

	Descriptions of section entries:

	M: Maintainer: FullName <address@domain>
	R: Designated reviewer: FullName <address@domain>
	These reviewers should be CCed on patches.
	L: Mailing list that is relevant to this area
	W: Web-page with status/info
	Q: Patchwork web based patch tracking system site
	T: SCM tree type and location.
	Type is one of: git, hg, quilt, stgit, topgit
	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.
	F: Files and directories with wildcard patterns.
	A trailing slash includes all files and subdirectory files.
	F: drivers/net/ all files in and below drivers/net
	F: drivers/net/* all files in drivers/net, but not below
	F: /net/ all files in "any top level directory"/net
	One pattern per line. Multiple F: lines acceptable.
	N: Files and directories with regex patterns.
	N: [^a-z]tegra all files whose path contains the word tegra
	One pattern per line. Multiple N: lines acceptable.
	scripts/get_maintainer.pl has different behavior for files that
	match F: pattern and matches of N: patterns. By default,
	get_maintainer will not look at git log history when an F: pattern
	match occurs. When an N: match occurs, git log history is used
	to also notify the people that have git commit signatures.
	X: Files and directories that are NOT maintained, same rules as F:
	Files exclusions are tested before file matches.
	Can be useful for excluding a specific subdirectory, for instance:
	F: net/
	X: net/ipv6/
	matches all files in and below net excluding net/ipv6/
	K: Keyword perl extended regex pattern to match content in a
	patch or file. For instance:
	K: of_get_profile
	matches patches or files that contain "of_get_profile"
	K: \b(printk\|pr_(info\|err))\b
	matches patches or files that contain one or more of the words
	printk, pr_info or pr_err
	One regex pattern per line. Multiple K: lines acceptable.

	Note: For the hard of thinking, this list is meant to remain in alphabetical
	order. If you could add yourselves to it in alphabetical order that would be
	so much easier [Ed]

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

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

	RISC-V ARCHITECTURE
	M: Ronald Minnich <rminnich@gmail.com>
	S: Maintained
	F: src/arch/riscv/
	F: src/mainboard/emulation/qemu-riscv/

	GOOGLE PANTHER MAINBOARD
	M: Stefan Reinauer <stefan.reinauer@coreboot.org>
	S: Supported
	F: src/mainboard/google/panther/

	INTEL MINNOWBOARD MAX MAINBOARD
	M: Martin Roth <gaumless@gmail.com>
	S: Maintained
	F: src/mainboard/intel/minnowmax/

	INTEL FSP BAYTRAIL CHIP
	M: Martin Roth <gaumless@gmail.com>
	S: Odd Fixes
	F: src/soc/intel/fsp_baytrail/

	INTEL FSP 1.0
	M: Martin Roth <gaumless@gmail.com>
	S: Odd Fixes
	F: src/drivers/intel/fsp1_0/
	F: src/vendorcode/intel/fsp1_0/

	ATI MACH64 Driver
	S: Orphan
	F: drivers/ati/mach64/

	LINT SCRIPTS
	M: Patrick Georgi <patrick@georgi-clan.de>
	S: Supported
	F: util/lint/

	BUILD SYSTEM
	M: Patrick Georgi <patrick@georgi-clan.de>
	M: Martin Roth <gaumless@gmail.com>
	S: Supported
	F: Makefile
	F: *.inc
	F: util/kconfig/
	F: util/sconfig/

	THE REST
	M: Stefan Reinauer <stefan.reinauer@coreboot.org>
	L: coreboot@coreboot.org
	T: git http://review.coreboot.org/coreboot
	S: Buried alive in mainboards
	F: *
	F: */