MAINTAINERS: Update instructions
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I0e06ac5f92109757143897f3d331aeea0cefe4b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68705
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
diff --git a/MAINTAINERS b/MAINTAINERS
index 131aea6..4627a58 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14,27 +14,17 @@
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!)
+1. Make sure your changes compile correctly in multiple configurations. In
+ particular check that changes work for various boards in the tree that
+ it affects:
-3. Make sure your changes compile correctly in multiple
- configurations. In particular check that changes work for all
- boards in the tree (use abuild!)
+ Test with: `util/abuild/abuild -c $(nproc) -t vendor/boardname`
-4. When you are happy with a change make it generally available for
+2. 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
+3. 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
@@ -45,36 +35,27 @@
(util/lint/checkpatch.pl) to catch trival style violations.
See https://www.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
+ ALWAYS remember that submissions are 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
https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure.
-6. Make sure you have the right to send any changes you make. If you
+4. 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.
+5. Happy hacking.
Descriptions of section entries:
M: Maintainer: FullName <address@domain>
Must be registered to Gerrit (https://review.coreboot.org/).
- Should have experience with upstream coreboot development.
+ Should have experience with upstream coreboot development and
+ +2 rights.
R: Designated reviewer: FullName <address@domain>
These reviewers should be CCed on patches.
L: Mailing list that is relevant to this area