Re: extra search flags and params? (ispatch, replycount, ...)

[Rob Herring <robh@kernel.org>]

On Tue, Nov 28, 2023 at 11:49 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> On Tue, Nov 28, 2023 at 05:35:09PM +0000, Eric Wong wrote:
> > > I understand the reasoning, but I'm not sure we should be trying too hard to
> > > make public-inbox a patch tracking platform. What makes lei great is ability
> > > to automatically find and retrieve entire threads -- I feel like we should
> > > leave series tracking to other platforms that already exist (patchwork,
> > > patchew, etc).

patch tracking platforms might want to use public-inbox to get the
patches in the first place.

> >
> > I was thinking more along the lines of readers just trying to
> > find trying to find non-patch discussions.

I do this time to time to find things I miss. Since I have patch
tracking, I don't miss patches.

> Ah. I think here is enough to just say "s:* AND NOT s:PATCH" without
> introducing additional xapian indexing parameters. Though, perhaps the web
> interface can also gain a "collapse threads" view?

There's also [RFC 1/N], [PATCHv5], or just [vN], so:

"s:* AND NOT (s:PATCH OR s:RFC OR s:v1 OR s:v2 OR s:v3...)"

But when someone does "[RFC] Things I want to discuss" or "blah blah
patch blah blah" it won't work. It's fragile and inexact.

We already have find certain patches with dfn:, why not find all patches?

Rob