Martin L Roth has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/68705 )
Change subject: MAINTAINERS: Update instructions ......................................................................
MAINTAINERS: Update instructions
Signed-off-by: Martin Roth gaumless@gmail.com Change-Id: I0e06ac5f92109757143897f3d331aeea0cefe4b9 --- M MAINTAINERS 1 file changed, 21 insertions(+), 30 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/05/68705/1
diff --git a/MAINTAINERS b/MAINTAINERS index 131aea6..093604d 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 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 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