From 286ed78a2e3251f8e6e7737a4165560a2920b1b6 Mon Sep 17 00:00:00 2001 From: Tom Rini Date: Mon, 29 Aug 2022 12:59:34 -0400 Subject: doc: process, sending_patches: Update and correct the old "Patches" content - Use gender-neutral language to refer to the user, consistently. - Reference the checkpatch document. - Move the section on commit message tags to the process document and reference this in sending_patches.rst. - Reword the custodian workflow process section to refer to this new section, integrate some of the wording from there in this new section. - Update the comment about GPLv2 applying to August 2022, to be clear this still is correct. - Reword the section about MAKEALL to talk about local build testing and link to the CI document. - Reference the system_configuration document for the note about modifying existing code. - Reword the patchwork flow section. Cc: Heinrich Schuchardt Signed-off-by: Tom Rini --- doc/develop/process.rst | 85 +++++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 71 insertions(+), 14 deletions(-) (limited to 'doc/develop/process.rst') diff --git a/doc/develop/process.rst b/doc/develop/process.rst index 6a18a8104aa..0fa0143bf37 100644 --- a/doc/develop/process.rst +++ b/doc/develop/process.rst @@ -129,31 +129,88 @@ patch, these should leave no doubt if they were just comments and the patch will be accepted anyway, or if the patch should be reworked/resubmitted, or if it was rejected. -Work flow of a Custodian +Review Process, Git Tags ------------------------ -The normal flow of work in the U-Boot development process will look -like this: +There are a number of *git tags* that are used to document the origin and the +processing of patches on their way into the mainline U-Boot code. The following +is an attempt to document how these are usually handled in the U-Boot project. + +In general, we try to follow the established procedures from other projects, +especially the Linux kernel, but there may be smaller differences. For +reference, see the Linux kernel's `Submitting patches +`_ +document. -#. A developer submits a patch via e-mail to the u-boot mailing list. In - U-Boot, we make use of the `Developer Certificate of Origin - `_ that is common in other projects such - as the Linux kernel. Following this and adding a ``Signed-off-by:`` line - that contains the developer's name and email address is required. +.. _dco: + +* Signed-off-by: the *Signed-off-by:* is a line at the end of the commit + message by which the signer certifies that they were involved in the development + of the patch and that they accept the `Developer Certificate of Origin + `_. Following this and adding a + ``Signed-off-by:`` line that contains the developer's name and email address + is required. + + * Please note that in U-Boot, we do not add a ``Signed-off-by`` tag if we + just pass on a patch without any changes. * Please note that when importing code from other projects you must say where it comes from, and what revision you are importing. You must not however copy ``Signed-off-by`` or other tags. -#. Everybody who can is invited to review and test the changes. Typically, we - follow the same guidelines as the Linux kernel for `Acked-by - `_ - as well as `Reviewed-by - `_ - and similar additional tags. +* Everybody who can is invited to review and test the changes. Typically, we + follow the same guidelines as the Linux kernel for `Acked-by + `_ + as well as `Reviewed-by + `_ + and similar additional tags. + +* Reviewed-by: The patch has been reviewed and found acceptible according to + the `Reveiwer's statement of oversight + `_. + A *Reviewed-by:* tag is a statement of opinion that the patch is an + appropriate modification of the code without any remaining serious technical + issues. Any interested reviewer (who has done the work) can offer a + *Reviewed-by:* tag for a patch. + +* Acked-by: If a person was not directly involved in the preparation or + handling of a patch but wishes to signify and record their approval of it + then they can arrange to have an *Acked-by:* line added to the patch's + changelog. + +* Tested-by: A *Tested-by:* tag indicates that the patch has been successfully + tested (in some environment) by the person named. Andrew Morton: "I think + it's very useful information to have. For a start, it tells you who has the + hardware and knows how to build a kernel. So if you're making a change to a + driver and want it tested, you can troll the file's changelog looking for + people who might be able to help." + +* Reported-by: If this patch fixes a problem reported by somebody else, + consider adding a *Reported-by:* tag to credit the reporter for their + contribution. Please note that this tag should not be added without the + reporter's permission, especially if the problem was not reported in a public + forum. + +* Cc: If a person should have the opportunity to comment on a patch, you may + optionally add a *Cc:* tag to the patch. Git tools (git send-email) will then + automatically arrange that they receives a copy of the patch when you submit it + to the mainling list. This is the only tag which might be added without an + explicit action by the person it names. This tag documents that potentially + interested parties have been included in the discussion. + For example, when your change affects a specific board or driver, then makes + a lot of sense to put the respective maintainer of this code on Cc: + +Work flow of a Custodian +------------------------ + +The normal flow of work in the U-Boot development process will look +like this: #. The responsible custodian inspects this patch, especially for: + #. The commit message is useful, descriptive and makes correct and + appropraite usage of required *git tags*. + #. :doc:`codingstyle` #. Basic logic: -- cgit