From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 46ADD1F619; Thu, 19 Mar 2020 07:22:24 +0000 (UTC) Date: Thu, 19 Mar 2020 07:22:24 +0000 From: Eric Wong To: meta@public-inbox.org Subject: Re: How to force stricter threading Message-ID: <20200319072224.GA12221@dcvr> References: <20200309131539.wx56ntf7cb3gpozh@chatter.i7.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200309131539.wx56ntf7cb3gpozh@chatter.i7.local> List-Id: Konstantin Ryabitsev 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...