[2/4] contributor-guide: recipe-style-guide: add some more patch tagging examples

Signed-off-by: Roland Hieber <rhi@pengutronix.de>
---
 .../contributor-guide/recipe-style-guide.rst     | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

On 20.09.23 at 12:06, Roland Hieber wrote:
> Signed-off-by: Roland Hieber <rhi@pengutronix.de>
> ---
>   .../contributor-guide/recipe-style-guide.rst     | 16 ++++++++++++++++
>   1 file changed, 16 insertions(+)
>
> diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst
> index 52ab4523c49f..4faadcd122d8 100644
> --- a/documentation/contributor-guide/recipe-style-guide.rst
> +++ b/documentation/contributor-guide/recipe-style-guide.rst
> @@ -347,6 +347,22 @@ Here's an example of a patch that has been submitted upstream::
>   A future update can change the value to ``Accepted`` or ``Denied`` as
>   appropriate.
>   
> +Another example of a patch that is specific to OpenEmbedded::
> +
> +   Do not treat warnings as errors
> +
> +   There are additional warnings found with musl which are
> +   treated as errors and fails the build, we have more combinations
> +   than upstream supports to handle.
> +
> +   Upstream-Status: Inappropriate [oe specific]
> +
> +Here's a patch that has been backported from a pull request::
> +
> +   include missing sys/file.h for LOCK_EX
> +
> +   Upstream-Status: Backport [https://github.com/systemd/systemd/pull/28651]

Could we instead use an example giving a commit instead of a pull 
request? With a pull request (like this one), it's hard to see what the 
final commit was, and we have to follow the link to double check whether 
the request was merged or not.

Thanks
Michael.

On Wed, Sep 20, 2023 at 04:16:12PM +0200, Michael Opdenacker via lists.yoctoproject.org wrote:
> 
> On 20.09.23 at 12:06, Roland Hieber wrote:
> > Signed-off-by: Roland Hieber <rhi@pengutronix.de>
> > ---
> >   .../contributor-guide/recipe-style-guide.rst     | 16 ++++++++++++++++
> >   1 file changed, 16 insertions(+)
> > 
> > diff --git a/documentation/contributor-guide/recipe-style-guide.rst b/documentation/contributor-guide/recipe-style-guide.rst
> > index 52ab4523c49f..4faadcd122d8 100644
> > --- a/documentation/contributor-guide/recipe-style-guide.rst
> > +++ b/documentation/contributor-guide/recipe-style-guide.rst
> > @@ -347,6 +347,22 @@ Here's an example of a patch that has been submitted upstream::
> >   A future update can change the value to ``Accepted`` or ``Denied`` as
> >   appropriate.
> > +Another example of a patch that is specific to OpenEmbedded::
> > +
> > +   Do not treat warnings as errors
> > +
> > +   There are additional warnings found with musl which are
> > +   treated as errors and fails the build, we have more combinations
> > +   than upstream supports to handle.
> > +
> > +   Upstream-Status: Inappropriate [oe specific]
> > +
> > +Here's a patch that has been backported from a pull request::
> > +
> > +   include missing sys/file.h for LOCK_EX
> > +
> > +   Upstream-Status: Backport [https://github.com/systemd/systemd/pull/28651]
> 
> Could we instead use an example giving a commit instead of a pull request?
> With a pull request (like this one), it's hard to see what the final commit
> was, and we have to follow the link to double check whether the request was
> merged or not.

Yes, that also makes more sense to me. But note that GitHub URLs
pointing to a commit also work if the commit in question was not yet
merged (or even if it is only available in a fork), so you'd still have
to click on the URL or check for the commit ID in the Git repo yourself
to see if it was merged (however this way you have the commit ID
directly in the patch).

 - Roland

Hi Roland

On 21.09.23 at 10:52, Roland Hieber wrote:
> On Wed, Sep 20, 2023 at 04:16:12PM +0200, Michael Opdenacker via lists.yoctoproject.org wrote:
>> Could we instead use an example giving a commit instead of a pull request?
>> With a pull request (like this one), it's hard to see what the final commit
>> was, and we have to follow the link to double check whether the request was
>> merged or not.
> Yes, that also makes more sense to me. But note that GitHub URLs
> pointing to a commit also work if the commit in question was not yet
> merged (or even if it is only available in a fork), so you'd still have
> to click on the URL or check for the commit ID in the Git repo yourself
> to see if it was merged (however this way you have the commit ID
> directly in the patch).


Oh right, this makes sense.
Thanks in advance for the updates to your patch series.

Cheers
Michael.