How to force stricter threading

How to force stricter threading

[Konstantin Ryabitsev]

Hello:

I think public-inbox currently does some heuristic-based threading, 
which may actually not be that useful. For example:

https://lore.kernel.org/linux-renesas-soc/20200217101741.3758-1-geert+renesas@glider.be/

None of the [PATCH] messages have references or in-reply-to set, but for 
some reason they are threaded together. I can generally see this being 
useful for exact subject matches, but in this case all of the subjects 
are different (despite being similar).

Is there a way to enforce stricter threading rules?

-K

Re: How to force stricter threading

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> Hello:
> 
> I think public-inbox currently does some heuristic-based threading, 
> which may actually not be that useful. For example:
> 
> https://lore.kernel.org/linux-renesas-soc/20200217101741.3758-1-geert+renesas@glider.be/
> 
> None of the [PATCH] messages have references or in-reply-to set, but for 
> some reason they are threaded together. I can generally see this being 
> useful for exact subject matches, but in this case all of the subjects 
> are different (despite being similar).

That's a strange bug.  Will have to look at it another time.

> Is there a way to enforce stricter threading rules?

Right now, it's a combination of strict threading based on
references/in-reply-to and exact subject matching by hash.
It could be possible to disable the subject matching part...

But that case is a strange bug which I'll have to examine more
closely another time (maybe later this week, but more likely
next).

Re: How to force stricter threading

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> Hello:
> 
> I think public-inbox currently does some heuristic-based threading, 
> which may actually not be that useful. For example:
> 
> https://lore.kernel.org/linux-renesas-soc/20200217101741.3758-1-geert+renesas@glider.be/
> 
> None of the [PATCH] messages have references or in-reply-to set, but for 
> some reason they are threaded together. I can generally see this being 
> useful for exact subject matches, but in this case all of the subjects 
> are different (despite being similar).

So the "Patchwork summary for: linux-renesas-soc" message:

https://lore.kernel.org/linux-renesas-soc/158229483332.12219.5639020605006542672.git-patchwork-summary@kernel.org/raw

has the following header:

References: <20200217101741.3758-1-geert+renesas@glider.be>,
 <20200218112414.5591-1-geert+renesas@glider.be>,
 <20200218112449.5723-1-geert+renesas@glider.be>,
 <20200219153929.11073-1-geert+renesas@glider.be>,
 <20200218132217.21454-1-geert+renesas@glider.be>,
 <20200217103251.5205-1-geert+renesas@glider.be>

Which seems to have tied a bunch of unrelated threads together
as one, similar to how a merge commit works in git but is
unexpected and rare for mail threads.

> Is there a way to enforce stricter threading rules?

So I think the internal indexing database behavior is correct
in tying a bunch of unrelated threads together based on that
References: header.

But the thread rendering could be improved.  What mutt does
seems alright, but doesn't convey the "merge" scenario
(I think) your bot was going for...

Re: How to force stricter threading

[Eric Wong]

Eric Wong <e@yhbt.net> wrote:
> So the "Patchwork summary for: linux-renesas-soc" message:
> 
> https://lore.kernel.org/linux-renesas-soc/158229483332.12219.5639020605006542672.git-patchwork-summary@kernel.org/raw
> 
> has the following header:
> 
> References: <20200217101741.3758-1-geert+renesas@glider.be>,
>  <20200218112414.5591-1-geert+renesas@glider.be>,
>  <20200218112449.5723-1-geert+renesas@glider.be>,
>  <20200219153929.11073-1-geert+renesas@glider.be>,
>  <20200218132217.21454-1-geert+renesas@glider.be>,
>  <20200217103251.5205-1-geert+renesas@glider.be>
> 
> Which seems to have tied a bunch of unrelated threads together
> as one, similar to how a merge commit works in git but is
> unexpected and rare for mail threads.

<snip>

> But the thread rendering could be improved.  What mutt does
> seems alright, but doesn't convey the "merge" scenario
> (I think) your bot was going for...

Fwiw, RFC 5322 sec 3.6.4 states:

	Therefore, trying to form a "References:" field for a reply that
	has multiple parents is discouraged; how to do so is not defined
	in this document.

So there's also that...

Re: How to force stricter threading

[Konstantin Ryabitsev]

On Thu, Mar 19, 2020 at 07:58:20AM +0000, Eric Wong wrote:
> > So the "Patchwork summary for: linux-renesas-soc" message:
> > 
> > https://lore.kernel.org/linux-renesas-soc/158229483332.12219.5639020605006542672.git-patchwork-summary@kernel.org/raw
> > 
> > has the following header:
> > 
> > References: <20200217101741.3758-1-geert+renesas@glider.be>,
> >  <20200218112414.5591-1-geert+renesas@glider.be>,
> >  <20200218112449.5723-1-geert+renesas@glider.be>,
> >  <20200219153929.11073-1-geert+renesas@glider.be>,
> >  <20200218132217.21454-1-geert+renesas@glider.be>,
> >  <20200217103251.5205-1-geert+renesas@glider.be>
> > 
> > Which seems to have tied a bunch of unrelated threads together
> > as one, similar to how a merge commit works in git but is
> > unexpected and rare for mail threads.

Thanks for tracking that down.

> > But the thread rendering could be improved.  What mutt does
> > seems alright, but doesn't convey the "merge" scenario
> > (I think) your bot was going for...
> 
> Fwiw, RFC 5322 sec 3.6.4 states:
> 
> 	Therefore, trying to form a "References:" field for a reply that
> 	has multiple parents is discouraged; how to do so is not defined
> 	in this document.
> 
> So there's also that...

I'll plan to stop adding these to the References: header and just give 
lore.kernel.org/r/<msgid> links. I don't think anyone would care and it 
will avoid this problem.

Thanks again,
-K