Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Vincent Fazio <vfazio@gmail.com>
Cc: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>,
	Ricardo Martincoski <ricardo.martincoski@datacom.com.br>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH v2 1/3] docs/manual: rewrite section for upstream documentation
Date: Sat, 15 Apr 2023 19:54:30 +0200	[thread overview]
Message-ID: <20230415175430.GR2819@scaer> (raw)
In-Reply-To: <20230403144105.419341-1-vfazio@gmail.com>

Vincent, All,

On 2023-04-03 09:41 -0500, Vincent Fazio spake thusly:
> 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>

Whole series applied to master, thanks.

I just had to regenerate .checkpackageignore on the last patch, but that
was expected, as new stuff had been comitted to master since your patch.

Thanks!

Regards,
Yann E. MORIN.

> ---
> Changes v1 -> v2:
>   - Minor updates commit message body
> ---
>  docs/manual/patch-policy.txt | 35 ++++++++++++++++++++++++-----------
>  1 file changed, 24 insertions(+), 11 deletions(-)
> 
> diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
> index 063ef984d8..dc35132ecf 100644
> --- a/docs/manual/patch-policy.txt
> +++ b/docs/manual/patch-policy.txt
> @@ -144,24 +144,37 @@ AC_PROG_MAKE_SET
>  +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
> -add a few things in the header of the patch itself.
> +Ideally, all patches should document an upstream patch or patch submission, when
> +applicable, via the +Upstream+ trailer.
>  
> -Depending on whether the patch has been obtained from the project
> -repository itself, or from somewhere on the web, add one of the
> -following tags:
> +When backporting an upstream patch that has been accepted into mainline, it is
> +preferred that the URL to the commit is referenced:
>  
>  ---------------
> -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
> -that may have been necessary.
> +Patches that have been submitted but were denied upstream should note that and
> +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.
> \ No newline at end of file
> -- 
> 2.34.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  parent reply	other threads:[~2023-04-15 17:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-03 14:41 [Buildroot] [PATCH v2 1/3] docs/manual: rewrite section for upstream documentation Vincent Fazio
2023-04-03 14:41 ` [Buildroot] [PATCH v2 2/3] utils/checkpackagelib: check for Upstream trailers Vincent Fazio
2023-04-03 14:41 ` [Buildroot] [PATCH v2 3/3] .checkpackageignore: add entries missing Upstream trailer Vincent Fazio
2023-04-15 17:54 ` Yann E. MORIN [this message]
2023-04-23  9:43 ` [Buildroot] [PATCH v2 1/3] docs/manual: rewrite section for upstream documentation Peter Korsgaard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230415175430.GR2819@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@buildroot.org \
    --cc=ricardo.martincoski@datacom.com.br \
    --cc=thomas.de_schampheleire@nokia.com \
    --cc=vfazio@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox