* |WARNING| pw153422 [PATCH] doc: reword contributor's guidelines
[not found] <20250512144842.29976-1-nandinipersad361@gmail.com>
@ 2025-05-12 14:14 ` qemudev
2025-05-12 14:50 ` |SUCCESS| " checkpatch
2025-05-12 16:22 ` |WARNING| " dpdklab
2 siblings, 0 replies; 3+ messages in thread
From: qemudev @ 2025-05-12 14:14 UTC (permalink / raw)
To: test-report; +Cc: Nandini Persad, zhoumin
Test-Label: loongarch-compilation
Test-Status: WARNING
http://dpdk.org/patch/153422
_apply patch failure_
Submitter: Nandini Persad <nandinipersad361@gmail.com>
Date: Mon, 12 May 2025 07:48:41 -0700
DPDK git baseline: Repo:dpdk
Branch: main
CommitID: 75f179ebe347b6098cf3af26d3d3b7168fe3fe24
Apply patch set 153422 failed:
Checking patch doc/guides/contributing/linux_uapi.rst...
Checking patch doc/guides/contributing/patches.rst...
error: while searching for:
git clone git://dpdk.org/next/dpdk-next-*
git clone https://dpdk.org/git/next/dpdk-next-*
Make your Changes
-----------------
Make your planned changes in the cloned ``dpdk`` repo. Here are some guidelines and requirements:
* Follow the :ref:`coding_style` guidelines.
* If you are a new contributor, or if your mail address changed,
you may update the ``.mailmap`` file.
Otherwise the new name or address will be added by a maintainer.
Keeping this file up-to-date will help when someone wants to contact you
about the changes you contributed to.
* If you add new files or directories you should add your name to the ``MAINTAINERS`` file.
* Initial submission of new PMDs should be prepared against a corresponding repo.
* Thus, for example, initial submission of a new network PMD should be
prepared against dpdk-next-net repo.
* Likewise, initial submission of a new crypto or compression PMD should be
prepared against dpdk-next-crypto repo.
* For other PMDs and more info, refer to the ``MAINTAINERS`` file.
* New external functions should be added to the local ``version.map`` file. See
the :doc:`ABI policy <abi_policy>` and :ref:`ABI versioning <abi_versioning>`
guides. New external functions should also be added in alphabetical order.
* Any new API function should be used in ``/app`` test directory.
* When introducing a new device API, at least one driver should implement it.
* Important changes will require an addition to the release notes in ``doc/guides/rel_notes/``.
See the :ref:`Release Notes section of the Documentation Guidelines <doc_guidelines>` for details.
* Test the compilation works with different targets, compilers and options, see :ref:`contrib_check_compilation`.
* Don't break compilation between commits with forward dependencies in a patchset.
Each commit should compile on its own to allow for ``git bisect`` and continuous integration testing.
* Add tests to the ``app/test`` unit test framework where possible.
* Add documentation, if relevant, in the form of Doxygen comments or a User Guide in RST format.
See the :ref:`Documentation Guidelines <doc_guidelines>`.
* Code and related documentation must be updated atomically in the same patch.
Once the changes have been made you should commit them to your local repo.
For small changes, that do not require specific explanations, it is better to keep things together in the
same patch.
Larger changes that require different explanations should be separated into logical patches in a patchset.
A good way of thinking about whether a patch should be split is to consider whether the change could be
applied without dependencies as a backport.
As a guide to how patches should be structured run ``git log`` on similar files.
Commit Messages: Subject Line
error: patch failed: doc/guides/contributing/patches.rst:135
error: doc/guides/contributing/patches.rst: patch does not apply
Checking patch doc/guides/contributing/stable.rst...
Checking patch doc/guides/contributing/vulnerability.rst...
^ permalink raw reply [flat|nested] 3+ messages in thread