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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Nov 28, 2023 at 11:49 AM Konstantin Ryabitsev
<konstantin@xxxxxxxxxxxxxxxxxxx> 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





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux