README: rework contribution advices

Remove description of coding standards and patch submission process.
Link to the relevant HTML documentation instead.

Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This commit is contained in:
Heinrich Schuchardt 2023-01-25 19:14:57 +01:00
parent cf69dc7458
commit 1405bfdfd0

110
README
View file

@ -2862,108 +2862,10 @@ void no_more_time (int sig)
}
Coding Standards:
-----------------
Contributing
============
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
sources.
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.
Submitting Patches:
-------------------
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@lists.denx.de>;
see https://lists.denx.de/listinfo/u-boot
When you send a patch, please include the following information with
it:
* 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
implementation.
* 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.
Notes:
* 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
modification.
* 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.