GNUBoot/coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Documentation: Encourage documentation with code changes

Browse source 
The resource allocator woes post-4.12 release showed room for
improvement on both discussion and documentation.  To encourage this
(and encourage reviewers to look out for issues in that space),
extend the review guidelines so that they encourage to more clearly
document the reason for a change with the change (commit message or
our documentation) and also to loop in the mailing list.

Change-Id: I1962dba3fe7e1a01fa4c8b0058297c7d050cb7b7
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/41493
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This commit is contained in:
Patrick Georgi 2020-05-17 22:10:53 +02:00
parent 64e15aac1b
commit 736024afdb
1 changed files with 17 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
Documentation/getting_started/gerrit_guidelines.md
View file

@ -254,6 +254,23 @@ commit message itself:
The script 'util/gitconfig/rebase.sh' can be used to help automate this.
Other tags such as 'Commit-Queue' can simply be removed.
* Check if there's documentation that needs to be updated to remain current
after your change. If there's no documentation for the part of coreboot
you're working on, consider adding some.
* When contributing a significant change to core parts of the code base (such
as the boot state machine or the resource allocator), or when introducing
a new way of doing something that you think is worthwhile to apply across
the tree (e.g. board variants), please bring up your design on the [mailing
list](../community/forums.md). When changing behavior substantially, an
explanation of what changes and why may be useful to have, either in the
commit message or, if the discussion of the subject matter needs way more
space, in the documentation. Since "what we did in the past and why it isn't
appropriate anymore" isn't the most useful reading several years down the road,
such a description could be put into the release notes for the next version
(that you can find in Documentation/releases/) where it will inform people
now without cluttering up the regular documentation, and also gives a nice
shout-out to your contribution by the next release.
Expectations contributors should have
-------------------------------------