summaryrefslogtreecommitdiff
path: root/doc/develop/codingstyle.rst
diff options
context:
space:
mode:
authorTom Rini <[email protected]>2026-07-06 08:12:19 -0600
committerTom Rini <[email protected]>2026-07-06 08:28:51 -0600
commit18761722e67d6e3770ab296a04fe3d40022e76d2 (patch)
treee544dae54d83d5d3524e527c435be0395efe3a17 /doc/develop/codingstyle.rst
parenta25c9bd19215ddd95d7494ebf8d842c46fdf3ba8 (diff)
parent91b94aff149d2c6efe3afa81adaf5edcc6119221 (diff)
Merge patch series "Remove patman from the U-Boot tree"
Simon Glass <[email protected]> says: patman is now maintained as a standalone 'patch-manager' package, so remove it from the tree. The command becomes a stub that tells people to run 'pip install patch-manager'. buildman still imports the shared modules commit and patchstream (along with their dependencies), so this series leaves those in place. It drops the tool's code, tests, CI hooks and packaging, and removes the in-tree documentation, moving the b4 contributor guide alongside the patman note in the patch-sending docs. It also adds a .patman-defaults file so the external tool is set up for U-Boot, next to the existing .b4-config. Where the CI jobs relied on patman's requirements for the setuptools that pylibfdt needs, they now install scripts/dtc/pylibfdt/requirements.txt instead. More could be done here: commit and patchstream (and their dependencies series, get_maintainer and settings) only remain because buildman still imports them. A follow-up could move those into u_boot_pylib (or buildman itself) and drop the rest, leaving tools/patman as just the stub. Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'doc/develop/codingstyle.rst')
-rw-r--r--doc/develop/codingstyle.rst48
1 files changed, 0 insertions, 48 deletions
diff --git a/doc/develop/codingstyle.rst b/doc/develop/codingstyle.rst
index 26881cf3900..b8d2bf23a54 100644
--- a/doc/develop/codingstyle.rst
+++ b/doc/develop/codingstyle.rst
@@ -24,54 +24,6 @@ The following rules apply:
<https://peps.python.org/pep-0008/>`_. Use `pylint
<https://github.com/pylint-dev/pylint>`_ for checking the code.
-.. _b4_contrib:
-
-* Use the `b4 <https://b4.docs.kernel.org/en/latest/>`__ tool to prepare and
- send your patches. b4 has become the preferred tool to sending patches for many
- Linux kernel contributors, and U-Boot ships with a ready-to-use ``.b4-config`` that
- targets ``[email protected]`` and integrates with ``scripts/get_maintainer.pl`` for
- recipient discovery.
-
- Start a topical series with ``b4 prep`` and keep the commits organised with
- ``git rebase -i``. ``b4 prep --edit-cover`` opens an editor for the cover
- letter, while ``b4 prep --auto-to-cc`` collects reviewers and maintainers from
- both the configuration file and ``scripts/get_maintainer.pl``.
-
- .. code-block:: bash
-
- b4 prep -n mmc-fixes
- git rebase -i origin/master
- b4 prep --edit-cover
- b4 prep --auto-to-cc
-
- Run the style checks before sending. ``b4 prep --check`` wraps the existing
- tooling so you see the output from ``scripts/checkpatch.pl`` alongside b4's
- own validation. You can always invoke ``scripts/checkpatch.pl`` directly for
- additional runs.
-
- .. code-block:: bash
-
- b4 prep --check
-
- When the series is ready, use ``b4 send``. Begin with ``--dry-run`` to review
- the generated emails and ``--reflect`` to copy yourself for records before
- dispatching to ``[email protected]``.
-
- .. code-block:: bash
-
- b4 send --dry-run
- b4 send --reflect
- b4 send
-
- After reviews arrive, collect Acked-by/Tested-by tags with ``b4 trailers -u``
- and fold them into your commits before resending the updated series.
-
- .. code-block:: bash
-
- b4 trailers -u
- git rebase -i origin/master
- b4 send
-
* Run ``scripts/checkpatch.pl`` directly or via ``b4 prep --check`` so that all
issues are resolved *before* posting on the mailing list. For more information,
read :doc:`checkpatch`.