ref-manual/faq: Add entry about emails on patch merging

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 | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

On Fri, Oct 30, 2026 at 8:33 AM Richard Purdie via docs <richard.purdie=
linuxfoundation.org@lists.yoctoproject.org> 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 | 19 +++++++++++++++++++
>  1 file changed, 19 insertions(+)
>
> diff --git a/documentation/ref-manual/faq.rst
> b/documentation/ref-manual/faq.rst
> index 3646286a6..6b1707733 100644
> --- a/documentation/ref-manual/faq.rst
> +++ b/documentation/ref-manual/faq.rst
> @@ -88,6 +88,25 @@ 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?
> +----------------------------------------------
> +
> +The project hasn't felt it necessary 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 be
> +emails direct to the submitter.
> +
> +Secondly, sending such emails accurately, takes time and it wasn't felt
> to be the
> +best use of limited maintainewr 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.
> +
>

This belongs to openembedded IMO, so perhaps oe-core README is better
suited for this


> +
>  Building environment
>  ====================
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#10746):
> https://lists.yoctoproject.org/g/docs/message/10746
> Mute This Topic: https://lists.yoctoproject.org/mt/122013256/1997914
> Group Owner: docs+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/docs/unsub [
> raj.khem@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

Hi Khem, Richard,

On 10/30/26 4:40 PM, Khem Raj via docs wrote:
> On Fri, Oct 30, 2026 at 8:33 AM Richard Purdie via docs <richard.purdie=
> linuxfoundation.org@lists.yoctoproject.org> 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 | 19 +++++++++++++++++++
>>   1 file changed, 19 insertions(+)
>>
>> diff --git a/documentation/ref-manual/faq.rst
>> b/documentation/ref-manual/faq.rst
>> index 3646286a6..6b1707733 100644
>> --- a/documentation/ref-manual/faq.rst
>> +++ b/documentation/ref-manual/faq.rst
>> @@ -88,6 +88,25 @@ 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?
>> +----------------------------------------------
>> +
>> +The project hasn't felt it necessary 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 be

the last "be" doesn't make sense in the context of the sentence.

>> +emails direct to the submitter.
>> +
>> +Secondly, sending such emails accurately, takes time and it wasn't felt
>> to be the
>> +best use of limited maintainewr time. We do track patch status to some
>> level

s/maintainewr/maintainer/

>> +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.
>> +
>>
> 
> This belongs to openembedded IMO, so perhaps oe-core README is better
> suited for this
> 

We definitely need this very visible (and the docs is such a place) 
because I've heard again at OSSE at least one person complaining about 
this (and I've complained about this in the past too). I still think 
it's a mistake to not do it and that it's adding enough friction that 
people aren't encouraged in contributing more. But I'm also no 
maintainer in Yocto and I know they are overloaded, so I understand it 
may be asking too much right now. I will not debate on the content of 
this patch as it's the position of the project (for years now).

Cheers,
Quentin

On Fri, 2026-10-30 at 17:14 +0100, Quentin Schulz wrote:
> We definitely need this very visible (and the docs is such a place) 
> because I've heard again at OSSE at least one person complaining
> about this (and I've complained about this in the past too). I still
> think it's a mistake to not do it and that it's adding enough
> friction that people aren't encouraged in contributing more. But I'm
> also no maintainer in Yocto and I know they are overloaded, so I
> understand it may be asking too much right now. I will not debate on
> the content of this patch as it's the position of the project (for
> years now).

You say you will "not debate it" yet you put forward all the arguments
and therefore I probably have to respond.

The ask is that I send an extra 100+ emails a week. Some of the
recipients will be happy. Some will very much not be. I'll then have to
write a process for people to say "yes I want these" or "no I don't"
and maintain lists which I then filter the responses against.

Yes, we have tools and there is automation which can help to a point.

Do we really want me to focus on that?

I can't even reply to the patches we're *not* taking. I struggle to get
volunteers in the patch review calls to respond to some patches.

The cost will be things like the layer changes, which are already
pushing me back to breaking point :(

I'm getting really frustrated that people just want to continue to say
"that is a mistake, I think you should be spending X hours a week doing
Y".

I already spend many hours a week doing lots of things which people
take for granted and just expect to happen. I don't really have
capacity to add more.

FWIW I do agree it is a lovely idea. 

I'd also note that someone else could sign up just to do this. They can
look at the patches merging and reply to the authors saying their patch
merged. Any volunteers to do that on an ongoing permanent basis?

No, I don't want an AI tool thrown over a wall I then get to
debug/fix/maintain, it needs a human to oversee it.

Cheers,

Richard