[PATCH v3] ref-manual/faq: Add entry about emails on patch merging

[PATCH v3] ref-manual/faq: Add entry about emails on patch merging

[Richard Purdie]

Document why we don't currently send emails when patches merge in the FAQ.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
---
 documentation/ref-manual/faq.rst | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
index 3646286a6..c1657d677 100644
--- a/documentation/ref-manual/faq.rst
+++ b/documentation/ref-manual/faq.rst
@@ -88,6 +88,26 @@ Our automated testing includes it through the ``poky-altcfg`` :term:`DISTRO` and
 we don't really need it to be the default: it is tested, it works, and people
 can choose to use it.
 
+Why don't I get an email when my patch merges?
+----------------------------------------------
+
+Where the project uses mailing lists for patch submission, many of the components
+such as bitbake and OpenEmbedded-Core haven't found it appropriate to reply on the
+mailing list for each patch that merges for two main reasons. Firstly, it would
+generate a lot of email traffic with content that may only be useful to a small
+number of people and quite annoying for other uninterested people to filter through.
+That could be avoided by only sending emails direct to the submitters.
+
+Secondly, sending such emails accurately, takes time and it wasn't felt to be the
+best use of limited maintainer time. We do track patch status to some level
+in patchwork and there is automated tooling which could extend on top of that but
+it hasn't been possible to fit that into the projects workflows with enough accuracy
+at this time.
+
+It is very easy to check whether a patch has merged by looking at the repository, or
+pulling and rebasing.
+
+
 Building environment
 ====================
 

Re: [docs] [PATCH v3] ref-manual/faq: Add entry about emails on patch merging

[Antonin Godard]

Hi,

On Sat Oct 31, 2026 at 12:02 AM CET, Richard Purdie via docs wrote:
> Document why we don't currently send emails when patches merge in the FAQ.
>
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
> ---
>  documentation/ref-manual/faq.rst | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
>
> diff --git a/documentation/ref-manual/faq.rst b/documentation/ref-manual/faq.rst
> index 3646286a6..c1657d677 100644
> --- a/documentation/ref-manual/faq.rst
> +++ b/documentation/ref-manual/faq.rst
> @@ -88,6 +88,26 @@ Our automated testing includes it through the ``poky-altcfg`` :term:`DISTRO` and
>  we don't really need it to be the default: it is tested, it works, and people
>  can choose to use it.
>  
> +Why don't I get an email when my patch merges?
> +----------------------------------------------
> +
> +Where the project uses mailing lists for patch submission, many of the components
> +such as bitbake and OpenEmbedded-Core haven't found it appropriate to reply on the
> +mailing list for each patch that merges for two main reasons. Firstly, it would
> +generate a lot of email traffic with content that may only be useful to a small
> +number of people and quite annoying for other uninterested people to filter through.
> +That could be avoided by only sending emails direct to the submitters.
> +
> +Secondly, sending such emails accurately, takes time and it wasn't felt to be the

I feel like the second comma here isn't needed. I'll remove it when merging to
master-next.

> +best use of limited maintainer time. We do track patch status to some level
> +in patchwork and there is automated tooling which could extend on top of that but

We can add a link to https://patchwork.yoctoproject.org/. Can do that when merging.

> +it hasn't been possible to fit that into the projects workflows with enough accuracy
> +at this time.
> +
> +It is very easy to check whether a patch has merged by looking at the repository, or
> +pulling and rebasing.

Have we settled on the master-review/master-backlog process now? That is
something we could mention here (or somewhere else and xref here), with links to
branches, so at least people would know a bit more about the status of their
patch. But I am not sure how mature this process is as of today. Cc'ing Paul as
I think he might have worked on docs for this.

Otherwise the patch LGTM, the point above could be a follow-up.

Thanks,
Antonin