[10:38:51] <dcausse>	 lunch
[10:45:24] <atsukoito>	 dcausse: here's the CR for you, https://gerrit.wikimedia.org/r/1294949
[12:14:20] <dcausse>	 atsukoito: looking
[12:33:02] <atsukoito>	 dcausse: thanks!
[13:03:19] <ebernhardson>	 \o
[13:09:44] <inflatador>	 .o/
[13:11:00] <dcausse>	 o/
[13:30:49] <atsukoito>	 ebernhardson: hii
[13:31:06] <atsukoito>	 dcausse: shall we do a config backport tomorrow morning?
[13:31:13] <ebernhardson>	 howdy :)
[13:31:32] <ebernhardson>	 no backport window on fridays, but monday
[13:32:35] <dcausse>	 atsukoito: as Erik said, tomorrow might not work, there's a window later today but it's quite late for CET folks, monday morning works for me
[13:33:02] <atsukoito>	 let's do monday morning then
[13:33:05] <dcausse>	 +1
[13:35:41] <dcausse>	 just discoverd that we have tests/integration/config/cirrus-integration-test-runner.json, tempted to add more stuff to it like the opensearch image versions to check, seems cleaner to let cirrus own some of the config
[13:36:12] <ebernhardson>	 dcausse: yea go for it, i had pondered moving more image names/etc there but didn't really have a use case yet
[13:37:49] <ebernhardson>	 there was a talk linked in the #ai-coding slack that mention this grill-me skill. General idea is generate a plan, then invoke /grill-me to get it to ask you questions about the plan.  Tried yesterday and seems uesful
[13:37:51] <ebernhardson>	 https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md
[13:39:47] <ebernhardson>	 hmm, also we've managed to bascilly empty out incoming/ready for dev
[13:40:16] <ebernhardson>	 there are things in ready for dev, but it's all related work that's done by other teams (ttm server migration, wbsearchentities, etc.)
[13:40:23] <ebernhardson>	 s/ready for dev/incoming/
[13:41:50] <dcausse>	 yes... no triage on monday, started to work on T427070, will move to the board
[13:41:50] <stashbot>	 T427070: Adapt cirrus integration tests to check two opensearch versions - https://phabricator.wikimedia.org/T427070
[13:44:42] <dcausse>	 there's the redirect "design issue" stricking again at T427107 I think, it's a wishlist wondering if we should prioritize making redirects first-class citizen in cirrus someday
[13:44:43] <stashbot>	 T427107: False positives with dual intitle terms - https://phabricator.wikimedia.org/T427107
[13:45:11] <ebernhardson>	 by first-class, you mean as separate docs?
[13:45:44] <dcausse>	 yes, they'd be excluded most of the time but a keyword or something else would enable searching for them
[13:46:23] <dcausse>	 and also some variation in the current keywords to not search for the redirects array
[13:46:41] <dcausse>	 but all this needs some thinking
[13:47:28] <ebernhardson>	 seems plausible, would have to ponder.  https://meta.wikimedia.org/wiki/Talk:Community_Wishlist/W356 is a similar request
[13:47:41] <ebernhardson>	 well, thats where they requested something with redirects and i said the current structure doesn't support it
[13:48:10] <dcausse>	 yes that's the wishlist I was thinking of
[13:48:40] <dcausse>	 I feel that a cheap solution to just alter the behavior of intitle is not going to match the important use-cases
[13:50:51] <ebernhardson>	 reading back through T204089 to try and better understand the use case.  It seems plausible to have those mostly excluded, although i wonder if that will somehow turn into whack-a-mole
[13:50:52] <stashbot>	 T204089: CirrusSearch: Add filter for exclusion of redirects or finding only them - https://phabricator.wikimedia.org/T204089
[13:51:39] <dcausse>	 yes excluding is fine, search for them is harded in its current form
[13:52:13] <dcausse>	 if they were their own docs we could enable most of the keywords for them (insource and other things)
[13:53:10] <ebernhardson>	 yea i can see that being useful...hmm. Will try and think through what the design needs
[13:56:30] <dcausse>	 thanks!
[14:04:32] <pfischer>	 o/ today’s a retro slot. Are you up for one?
[14:06:36] <ebernhardson>	 sure, i don't have anything in particular but am available
[14:08:56] <dcausse>	 same
[14:11:11] <inflatador>	 I'm game
[14:12:05] <ebernhardson>	 hmm, incategory: and hastemplate: are probably also candidates beynd intitle: and insource:.  but it's easier to imagine modifiers like intitle:/foo/r, not sure about incategory and such.  alternate keywords sounds awkward, maybe just always have those query redirects 
[14:12:34] <inflatador>	 I'm working on a doc for the 1.x->2.x migration, I created a worst-case scenario section that could use some more details if anyone has the cycles: https://docs.google.com/document/d/1XJ6_9ZHJ7yluAOA8DMhxmdDhLJZn8HaA5ADokZLpbr8/edit?tab=t.0#heading=h.624ehc8exwfq
[14:13:12] <inflatador>	 Feel free to correct anything that's wrong
[14:20:15] <dcausse>	 ebernhardson: was thinking about a broader keyword like 'withredirects:' (added as a prefix to query), something that would turn off the "is_redirect: false" filter, individual keywords would remain almost the same, except intitle
[14:20:50] <ebernhardson>	 hmm, i suppose that would simplify things.  I was just pondering what it looks like to intitle:/foo.*bar/r intitle:/other/, and it's messy :P
[14:21:17] <ebernhardson>	 a top level page_type property paired with a top level filter would be simpler
[14:24:09] <Trey314159>	 late to reply but I'll try not to be late to the retro!
[15:04:20] <inflatador>	 Trey314159 pfischer I can't make the retro after all, double-booked with DPE SRE retro
[16:25:45] <ebernhardson>	 hmm, if we suddenly have documents for all the redirects, do we stop building prefix indexes for redirect.title and instead change near match and prefix search to query the redirects directly?
[16:25:59] <ebernhardson>	 but then we have the risk of duplicate results
[16:26:03] <ebernhardson>	 "duplicate"
[17:06:01] <dcausse>	 I think by default I would just keep things as is
[17:06:36] <dcausse>	 but I have no clue how the various UI/API will look like when the redirects mode is explcitly requested
[17:06:46] <ebernhardson>	 yea thats what i thought to, i like the idea of pulling back some indexing space, the prefix's on redirects (also not having the redirect limit) will take a bunch of space, but changing it seems risky
[17:07:02] <dcausse>	 I think it'd be the point to return multiple redirects to the same page
[17:07:54] <dcausse>	 yes... the redirect array limit is odd but IIRC I saw pages with multiple thousands of redirects
[17:08:09] <ebernhardson>	 the thing is, we will now have to index those thousands of docs. They will be small at least
[17:08:17] <ebernhardson>	 i mean, maybe not have to, but it seems wrong if we dont
[17:09:08] <dcausse>	 yes that's an open question what would be the cost... will we go from 9M docs to 90M, 900M in the main ns? and how bad that is
[17:11:26] <dcausse>	 50M pages within 65M titles (pages+redirects) if I trust Special:Statistics on enwiki
[17:11:34] <dcausse>	 was expecting something worse
[17:11:52] <ebernhardson>	 yea that's not nearly as bad as i was thinking, i was assuming 5-10x
[17:11:53] <dcausse>	 that's +15M docs to index
[17:12:04] <dcausse>	 other wikis could be worse tho
[17:12:10] <dcausse>	 yes me too
[17:12:51] <ebernhardson>	 i suppose i'll make a note to build out a proper estimate of size changes
[17:12:59] <dcausse>	 sure
[17:40:28] <dcausse>	 dinner