boost and /all/

boost and /all/

[Konstantin Ryabitsev]

Eric:

I'm not sure if boost is quite working correctly (or it's possible I'm not
doing something right). E.g. I have the following thread:

https://x-lore.kernel.org/all/d8319fd18df7086b12cdcc23193c313893aa071a.1627362340.git.viresh.kumar@linaro.org/T/#u

It was sent to several vger destinations, but also to the virtualization list,
which alters message bodies. I have vger sources marked with boost=1, but not
the virtualization source, e.g.:

	[publicinbox "lkml"]
	  address = linux-kernel@vger.kernel.org
	  url = https://x-lore.kernel.org/lkml/
	  inboxdir = /srv/public-inbox/lore.kernel.org/lkml
	  indexlevel = full
	  newsgroup = org.kernel.vger.linux-kernel
	  infourl = https://www.kernel.org/lore.html
	  boost = 1
	  listid = linux-kernel.vger.kernel.org

	[publicinbox "virtualization"]
	  address = virtualization@lists.linux-foundation.org
	  url = https://x-lore.kernel.org/virtualization/
	  inboxdir = /srv/public-inbox/lore.kernel.org/virtualization
	  indexlevel = full
	  newsgroup = org.linuxfoundation.lists.virtualization
	  infourl = https://www.kernel.org/lore.html
	  listid = virtualization.lists.linux-foundation.org

I believe this should assign boost value of 0, but the virtualization source
seems to be "winning" both via the interface and when retrieving t.mbox.gz.
Anything I'm not doing right?

-K

Re: boost and /all/

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> Eric:
> 
> I'm not sure if boost is quite working correctly (or it's possible I'm not
> doing something right). E.g. I have the following thread:
> 
> https://x-lore.kernel.org/all/d8319fd18df7086b12cdcc23193c313893aa071a.1627362340.git.viresh.kumar@linaro.org/T/#u
> 
> It was sent to several vger destinations, but also to the virtualization list,
> which alters message bodies. I have vger sources marked with boost=1, but not
> the virtualization source, e.g.:

<snip>

> I believe this should assign boost value of 0, but the virtualization source
> seems to be "winning" both via the interface and when retrieving t.mbox.gz.
> Anything I'm not doing right?

Correct, boost=0 is the default.  Did you set boost before indexing?
It needs to be set before indexing (or reindexing).

Reindexing is crazy expensive, unfortunately, and there probably
needs to be a way to limit it to certain messages...

Re: boost and /all/

[Konstantin Ryabitsev]

On Mon, Aug 02, 2021 at 09:16:56PM +0000, Eric Wong wrote:
> > I believe this should assign boost value of 0, but the virtualization source
> > seems to be "winning" both via the interface and when retrieving t.mbox.gz.
> > Anything I'm not doing right?
> 
> Correct, boost=0 is the default.  Did you set boost before indexing?
> It needs to be set before indexing (or reindexing).

Yes, all boost values were present from the start. On this particular
instance, I ended up indexing a few tiny lists first, and then /lkml/, and
only after that the remaining bulk of repositories, so this thread would have
first made its way in through /lkml/ and then through most other lists,
including /virtualization/. That shouldn't have caused /virtualization/ to
"win", should it?

-K

Re: boost and /all/

[Eric Wong]

Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Mon, Aug 02, 2021 at 09:16:56PM +0000, Eric Wong wrote:
> > > I believe this should assign boost value of 0, but the virtualization source
> > > seems to be "winning" both via the interface and when retrieving t.mbox.gz.
> > > Anything I'm not doing right?
> > 
> > Correct, boost=0 is the default.  Did you set boost before indexing?
> > It needs to be set before indexing (or reindexing).
> 
> Yes, all boost values were present from the start. On this particular
> instance, I ended up indexing a few tiny lists first, and then /lkml/, and
> only after that the remaining bulk of repositories, so this thread would have
> first made its way in through /lkml/ and then through most other lists,
> including /virtualization/. That shouldn't have caused /virtualization/ to
> "win", should it?

Oops, yes, there seems to be a bug across multiple invocations
(but not reindex), will try to fix it in a few.