[2/7] 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>
---
 README | 110 ++++-----------------------------------------------------
 1 file changed, 6 insertions(+), 104 deletions(-)

On Wed, Jan 25, 2023 at 07:14:57PM +0100, Heinrich Schuchardt wrote:

> 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>

On Wed, 25 Jan 2023 at 11:15, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
> 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>
> ---
>  README | 110 ++++-----------------------------------------------------
>  1 file changed, 6 insertions(+), 104 deletions(-)
>

Reviewed-by: Simon Glass <sjg@chromium.org>

Suggestion below

> diff --git a/README b/README
> index 24e91b9a1f..f5db75d913 100644
> --- a/README
> +++ b/README
> @@ -2862,108 +2862,10 @@ void no_more_time (int sig)
>  }
>
>
> -Coding Standards:
> ------------------
> -
> -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.
> +Contributing
> +============
>
> -* 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.

project

> +If you want to participate, please, have a look at the 'General'

To participate, please have a look

> +section of https://u-boot.readthedocs.io/en/latest/develop/index.html
> +where we describe coding standards and the patch submission process.

Should we mention the mailing list and irc?

Regards,
Simon