I don't think I have access to that information. The GitHub plugin (if that is being used) might have that info and could implement their own RecipientProvider which could then be used in email-ext.

Yeah, I suspected email-ext wouldn't have access to GH info.  It's interesting that another plugin can implement a recipientProvider.

Is my observation correct about a PR that merges other patches into it, such as say, merging another (i.e. master) branch, the single owner of the primary patch of the PR is lost and there is no existing recipientProvider that will distinguish that owner (of the primary patch) on the PR from all of the owners of patches in the merge?

Jenkins is full of such extension points. It makes it very extendable. I do not know about the owner of the primary patch being lost, but there is no recipient provider that I know about that does what you want.

I do not know about the owner of the primary patch being lost

Not lost, but not identifiable as the single individual for which the patches in the PR belong, among the many authors of the perhaps many patches that got added from a merged branch (i.e. again, when say, merging master to a PR).

I don't know of any way to identify that from the email-ext plugin perspective. Which plugin are you using for SCM?

I am using the github-branch-source plugin with pipelines.

Ultimately the problem is that (AFAICT) the most useful recipientProvider to use with a single PR is:

developers

• Sends email to all the people who caused a change in the change set.  

But as I mentioned before that list gets polluted with every author of every patch that was merged from a parent branch when doing a merge to get one's PR up-to-date with it's parent branch.

Correct, it looks through all of the changesets and grabs all the authors.