NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs/manual: rewrite section for upstream documentation

Browse Source 
Previously, the documentation only requested links to upstream commits
when backporting patches.

Based on a mailing list discussion [0], patches should, when possible
and when approriate, provide a link as evidence that the patch has been
submitted upstream.

The motivation is that hopefully the patch gets applied to upstream at
some point reducing the long term maintenance burden within Buildroot.
This also makes future patch review on subsequent package version bumps
more streamlined.

For patches that are unique to BR and do not apply to the upstream
repository, patches should have a comment explaining why they do not
apply upstream.

[0] https://lists.buildroot.org/pipermail/buildroot/2023-March/666000.html

Signed-off-by: Vincent Fazio <vfazio@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
(cherry picked from commit 5b00b40a05)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit is contained in:
Vincent Fazio 2023-04-03 09:41:03 -05:00 committed by Peter Korsgaard
parent f87fe6d419
commit d2b0ce01ba
1 changed files with 24 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

35
docs/manual/patch-policy.txt
View File

@ -144,24 +144,37 @@ AC_PROG_MAKE_SET
+AM_CONDITIONAL([CXX_WORKS], [test "x$rw_cv_prog_cxx_works" = "xyes"]) +AM_CONDITIONAL([CXX_WORKS], [test "x$rw_cv_prog_cxx_works" = "xyes"])
--------------- ---------------
=== Integrating patches found on the Web === Additional patch documentation
When integrating a patch of which you are not the author, you have to Ideally, all patches should document an upstream patch or patch submission, when
add a few things in the header of the patch itself. applicable, via the +Upstream+ trailer.
Depending on whether the patch has been obtained from the project When backporting an upstream patch that has been accepted into mainline, it is
repository itself, or from somewhere on the web, add one of the preferred that the URL to the commit is referenced:
following tags:
--------------- ---------------
Backported from: <some commit id> Upstream: <URL to upstream commit>
--------------- ---------------
or If a new issue is identified in Buildroot and upstream is generally affected by
the issue (it's not a Buildroot specific issue), users should submit the patch
upstream and provide a link to that submission when possible:
--------------- ---------------
Fetch from: <some url> Upstream: <URL to upstream mailing list submission or merge request>
--------------- ---------------
It is also sensible to add a few words about any changes to the patch Patches that have been submitted but were denied upstream should note that and
that may have been necessary. include comments about why the patch is being used despite the upstream status.
Note: in any of the above scenarios, it is also sensible to add a few words
about any changes to the patch that may have been necessary.
If a patch does not apply upstream then this should be noted with a comment:
---------------
Upstream: N/A <additional information about why patch is Buildroot specific>
---------------
Adding this documentation helps streamline the patch review process during
package version updates.