[07:54:06] o/ dcausse: I am looking into RDF releases. They show up on mvnrepository.com (https://mvnrepository.com/artifact/org.wikidata.query.rdf/service/0.3.156) but are hosted on archiva. Somehow mvnrepository.com aggregates archiva. Yet there are older versions on maven central (https://search.maven.org/search?q=org.wikidata.query.rdf). Do we want RDF artefacts to be deployed to central or rather internally to GitLab? [07:58:50] pfischer: o/, I think we should have them in gitlab [07:59:17] once there we should send an announce to wikidata ml to inform re-users of the new location [08:00:34] Alright. Thanks. [08:00:49] I could be wrong but I believe that re-users download these artifacts directly from archiva.wikimedia.org not central nor mvnrepository.com [08:01:55] mvnrepository is just an index. I was not aware of the fact that they aggregate repositories besides central. [08:03:02] Yesterday I processed the highlighter plugin in that in turn is published to central, that’s why I wondered why RDF is handled differently. [08:13:08] I belive Andrew told mvnrepository to pull archiva.wikimedia.org but could be wrong [08:13:44] RDF is definitely handled differently and switched several years from central to archiva.wm.o [08:13:50] *ago [09:58:28] lunch [11:14:43] gehel: could you have a look at the parent POM PR regarding the sonatype deployment, please? I’d need that to migrate central-released projects like our extra plugin. [11:14:48] org.wikimedia.search [11:14:57] https://gitlab.wikimedia.org/repos/maven/wmf-jvm-parent-pom/-/merge_requests/26/diffs [12:21:25] pfischer: minor suggestions as comments [13:10:05] o/ [13:56:17] gehel: thanks. fixed [14:01:25] \o [14:05:20] .o/ [14:27:02] o/ [14:31:56] pfischer, Trey314159 : we're in https://meet.google.com/diy-wsis-csm with Tara [14:59:26] is the separation of "back" and "requery" too much? https://phabricator.wikimedia.org/F60304739 [14:59:51] the general meaning is "back" is query that has already been performed in the session, and requery is 2+ unique queries [15:05:54] I like the updated diagram! Just looking at the diagram, I took "back" to be that you were able to detect or infer the searcher using the back button on the browser; but it sounds like it would include re-issuing the same query (which I've definitely done). Let me think some more about "back" vs "requery".... [15:06:48] that variant is also session normalized, which i haven't decided if i like. the problem is the flows then don't add up [15:07:15] but it avoids the session that does 10 autocomplete->targetpage cycles from being so influential [15:18:43] Navigationally, "back" and "requery" seem to be the same thing. From the stance of intent, they are a bit different..re-searching is not quite the same as reformulating or moving on to a new query. [15:18:49] OTOH, if I search for A, then B, then A again, then B again, how to code that? A := query, B := requery, A again := back, B again := back? Okay, that works (if detecting multiple repeats isn't too hard), and that specific kind of scenario probably won't be common. [15:18:51] I think I'm 55% in favor of keeping them distinct and can imagine (with infinite time, so maybe not really) comparing "back" sessions to multiple-"back" sessions to "re-query" sessions. I'd be okay with conflating them, too, though.. so not much help in making a decision! [15:19:13] *Conflating "back" and "requery" [15:19:15] :P [15:19:41] detecting multiples isn't hard, i just keep a set of seen queries while iterating the session [15:19:51] I figured [15:23:54] inflatador: I was on vacation when you asked about re-indexing, and I just got back today. Re-indexing failed, I don't like "learning" in production, and really I didn't want to leave it in a weird state when I was going on vacation, so I moved T393392 back to "ready for dev". It's on my list to discuss in the Wednesday meeting. [15:23:55] T393392: Reindex Czech-language wikis to enable diacritic folding - https://phabricator.wikimedia.org/T393392 [15:24:08] (Thanks for the reminder!) [15:58:31] Trey314159 welcome back! We can talk about it tomorrow at the Weds mtg [15:58:47] workout, back in ~40 [16:54:51] back [17:05:35] Trey314159: looked into your reindex thing, if you are trying to reindex eqiad the problem is it's in the middle of elastic->opensearch migration. Alternate reason would be that my plugin-aliasing bits only handles homogeneous clusters, it doesn't like that some plugin names change between elastic and opensearch [17:06:44] ebernhardson: thanks for looking. Sounds like waiting for the migration to finish is the easiest solution. We had discussed that, and I'm okay with waiting. [17:43:41] dinner [17:50:14] lunch, back in ~40 [18:32:43] pfischer: just in case, we're in the JVM meeting with Joseph and Aleks. Not sure if you're joining or not. [21:20:12] ryankemper we're in pairing if you wanna join [21:21:36] ryankemper NM, we ended early. But do ping me if you have anything to go over [21:44:05] OK, created T394851 to discuss ways to reduce complexity [21:44:06] T394851: Explore ways to reduce complexity of OpenSearch environment (specific suggestions below) - https://phabricator.wikimedia.org/T394851