diff options
| author | Tom Rini <[email protected]> | 2026-07-06 08:12:19 -0600 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2026-07-06 08:28:51 -0600 |
| commit | 18761722e67d6e3770ab296a04fe3d40022e76d2 (patch) | |
| tree | e544dae54d83d5d3524e527c435be0395efe3a17 /doc/develop/codingstyle.rst | |
| parent | a25c9bd19215ddd95d7494ebf8d842c46fdf3ba8 (diff) | |
| parent | 91b94aff149d2c6efe3afa81adaf5edcc6119221 (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.rst | 48 |
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`. |
