[PATCH 2/7] README: rework contribution advices
heinrich.schuchardt at canonical.com
Wed Jan 25 19:14:57 CET 2023
Remove description of coding standards and patch submission process.
Link to the relevant HTML documentation instead.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt at canonical.com>
README | 110 ++++-----------------------------------------------------
1 file changed, 6 insertions(+), 104 deletions(-)
diff --git a/README b/README
index 24e91b9a1f..f5db75d913 100644
@@ -2862,108 +2862,10 @@ void no_more_time (int sig)
-All contributions to U-Boot should conform to the Linux kernel
-coding style; see the kernel coding style guide at
-https://www.kernel.org/doc/html/latest/process/coding-style.html, and the
-script "scripts/Lindent" in your Linux kernel source directory.
-Source files originating from a different project (for example the
-MTD subsystem) are generally exempt from these guidelines and are not
-reformatted to ease subsequent migration to newer versions of those
-Please note that U-Boot is implemented in C (and to some small parts in
-Assembler); no C++ is used, so please do not use C++ style comments (//)
-in your code.
-Please also stick to the following formatting rules:
-- remove any trailing white space
-- use TAB characters for indentation and vertical alignment, not spaces
-- make sure NOT to use DOS '\r\n' line feeds
-- do not add more than 2 consecutive empty lines to source files
-- do not add trailing empty lines to source files
-Submissions which do not conform to the standards may be returned
-with a request to reformat the changes.
-Since the number of patches for U-Boot is growing, we need to
-establish some rules. Submissions which do not conform to these rules
-may be rejected, even when they contain important and valuable stuff.
-Please see https://www.denx.de/wiki/U-Boot/Patches for details.
-Patches shall be sent to the u-boot mailing list <u-boot at lists.denx.de>;
-When you send a patch, please include the following information with
-* For bug fixes: a description of the bug and how your patch fixes
- this bug. Please try to include a way of demonstrating that the
- patch actually fixes something.
-* For new features: a description of the feature and your
-* For major contributions, add a MAINTAINERS file with your
- information and associated file and directory references.
-* When you add support for a new board, don't forget to add a
- maintainer e-mail address to the boards.cfg file, too.
-* If your patch adds new configuration options, don't forget to
- document these in the README file.
-* The patch itself. If you are using git (which is *strongly*
- recommended) you can easily generate the patch using the
- "git format-patch". If you then use "git send-email" to send it to
- the U-Boot mailing list, you will avoid most of the common problems
- with some other mail clients.
- If you cannot use git, use "diff -purN OLD NEW". If your version of
- diff does not support these options, then get the latest version of
- GNU diff.
- The current directory when running this command shall be the parent
- directory of the U-Boot source tree (i. e. please make sure that
- your patch includes sufficient directory information for the
- affected files).
- We prefer patches as plain text. MIME attachments are discouraged,
- and compressed attachments must not be used.
-* If one logical set of modifications affects or creates several
- files, all these changes shall be submitted in a SINGLE patch file.
-* Changesets that contain different, unrelated modifications shall be
- submitted as SEPARATE patches, one patch per changeset.
-* Before sending the patch, run the buildman script on your patched
- source tree and make sure that no errors or warnings are reported
- for any of the boards.
-* Keep your modifications to the necessary minimum: A patch
- containing several unrelated changes or arbitrary reformats will be
- returned with a request to re-formatting / split it.
-* If you modify existing code, make sure that your new code does not
- add to the memory footprint of the code ;-) Small is beautiful!
- When adding new features, these should compile conditionally only
- (using #ifdef), and the resulting code with the new feature
- disabled must not need more memory than the old code without your
-* Remember that there is a size limit of 100 kB per message on the
- u-boot mailing list. Bigger patches will be moderated. If they are
- reasonable and not too big, they will be acknowledged. But patches
- bigger than the size limit should be avoided.
+The U-Boot projects depends on contributions from the user community.
+If you want to participate, please, have a look at the 'General'
+section of https://u-boot.readthedocs.io/en/latest/develop/index.html
+where we describe coding standards and the patch submission process.
More information about the U-Boot