[09:00:24] <pfischer>	 Howdy! I’m following my onboarding todos and one step is to become a member of the phab project Discovery (archived, now Discovery-Search). The members list only lists 3 accounts. How come? Is this the right place? https://phabricator.wikimedia.org/project/members/1849/
[09:04:40] <dcausse>	 pfischer: hey!
[09:05:21] <dcausse>	 looking, I'm not sure what "members" mean in phab
[09:05:45] <gehel>	 I think that this is only informational, so that other people might know that you are part of that team.
[09:06:15] <dcausse>	 "You are a member and you will receive mail that is sent to all project members"
[09:06:20] <dcausse>	 not sure I want this :)
[09:06:42] <gehel>	 I've added myself
[09:06:49] <dcausse>	 you're brave
[09:07:03] <gehel>	 dcausse: I see that you've added yourself as well!
[09:07:22] <gehel>	 Maybe we should just remove that step from the onboarding doc and template. pfischer: could you do that?
[09:07:24] <dcausse>	 I removed myself right after seeing that I'll receive all the notifications
[09:07:53] <gehel>	 I have too many notifications from phab anyway :/
[09:08:49] <gehel>	 pfischer: and thanks for updating T316090 ! I'll see if I can move it forward
[09:08:50] <stashbot>	 T316090: Production Shell access for Peter - https://phabricator.wikimedia.org/T316090
[09:09:24] <gehel>	 ejoseph: are you around for our 1:1?
[10:29:38] <gehel>	 lunch
[10:38:43] <dcausse>	 lunch 2
[11:48:25] <gehel>	 pfischer: Hey! How's life? Anything you're blocked on?
[11:50:29] <gehel>	 pfischer: if you can keep https://www.mediawiki.org/wiki/Wikimedia_Discovery/Team/Onboarding/Peter and https://office.wikimedia.org/wiki/Technology/Onboarding/Checklists/Peter up to date (strike what has already been done) that would be super helpful for me (and the rest of the team)
[11:50:46] <gehel>	 That way we have an idea of where you're at, and where you might need help.
[11:51:03] <pfischer>	 gehel thanks for asking, AFAIK I’m only waiting for production access. Up next: add my SSH key for non-prod stuff to gerrit
[11:51:20] <gehel>	 I was going to ask about gerrit access :)
[11:51:53] <pfischer>	 Already did a review, but haven’t cloned anything yet.
[11:52:33] <gehel>	 you should be able to add your SSH key in gerrit yourself. I can add you to a few groups. What is your gerrit username?
[12:00:36] <pfischer>	 pfischer
[12:01:21] <gehel>	 You are now part of the "search" group, which should give you access to most repositories that you need, including merge rights.
[12:02:56] <gehel>	 Obviously, use those rights with care. For code repositories, we have pretty strong policy of not self merging. There are exceptions, for example when you are the only one who actually understands the project well enough to take responsibility to merge. Even then, always have someone review before merging. (and yes, all that is probably obvious to you)
[12:03:49] <gehel>	 If you don't have previous experience with gerrit, you are likely to hate it for the next 6 months. After that, you'll be so used to it that you'll probably hate going back to something like github and pull requests...
[12:05:08] <gehel>	 The first project you'll be working on will be https://gerrit.wikimedia.org/r/admin/repos/search/cirrus-streaming-updater (mostly empty at the moment). But you can already clone it it you want.
[12:05:32] <gehel>	 there is a single open CR on that project: https://gerrit.wikimedia.org/r/c/search/cirrus-streaming-updater/+/826664
[12:05:45] <gehel>	 you are welcomed to review it and send your comments (or questions)
[12:06:34] <gehel>	 If you want an overview of gerrit, ping me or dcausse and we can jump in a Meet and show you a few things
[13:16:30] <gehel>	 dcausse: Hey! Would you have some time to jump in https://meet.google.com/qyw-uitx-ntw with Peter and me?
[13:16:44] <dcausse>	 sure
[13:16:44] <inflatador>	 greetings
[13:16:49] <dcausse>	 o/
[13:17:30] <inflatador>	 <o/
[14:57:39] <gehel>	 I was reminded about https://wikitech.wikimedia.org/wiki/Selling_to_Wikimedia_Foundation, which I should be using more often! Maybe someone else needs the reminder...
[14:58:59] <ebernhardson>	  \o
[14:59:43] <ebernhardson>	 sigh, CI failing with the most annoying reasons: Error while storing the mojo status: No space left on device -
[15:01:13] <dcausse>	 o/
[15:04:49] <ebernhardson>	 wonderful to see: "The new network design doesn't have this constraint, for example racks F1 and F2 are distinct failure models."
[15:05:23] <ebernhardson>	 i suppose it will take time, but that might allow us to relax the constraints in elastic about where shards are allowed
[15:06:08] <inflatador>	 OH yeah, I was looking at that too, but didn't fully grasp the implications
[15:10:27] <ebernhardson>	 ref is https://wikitech.wikimedia.org/wiki/Wikimedia_network_guidelines which network ops emailed about earlier if anyone else is wondering what i'm talking about :
[15:21:38] <inflatador>	 will not make unmtg today, too much sniffling/sore throat
[15:27:22] <pfischer>	 dcausse: quick catchup: for jvm-utils, mvn clean verify passes, however, for rdf, verify fails due to failing tests inside the sub project rdf-spark-tools
[15:55:43] <inflatador>	 medical appointment, back in ~45m
[16:15:13] * ebernhardson goes back to fighting poms...somehow my changes made rdf-spark-tools want to start up the integration proxy twice, and now it's also finding duplicate classes/resources that weren't there before my changes....fun :P
[16:15:33] <ebernhardson>	 i suspect somehow i've told it to run integration testing twice and the proxy doesn't turn off when it's supposed to
[16:44:47] <ebernhardson>	 is it safe to ignore dependencyManagement and pluginManagement in effective-pom?  Have those things all been pushed down into the dependency and plugin sections, or do i need to do that in my head while reading?
[16:51:29] <pfischer>	 ebernhardson: what do you mean by ignoring? (plugin|dependency)Management ere overruled by (plugin|dependency) sections
[16:52:54] <ebernhardson>	 pfischer: hmm, i guess i was hoping it would resolve the versions/scopes from the management sections into the final plugin|dependency sections (if it's not obvious, i'm only passingly familiar with jvm world :)
[16:55:01] <pfischer>	 ebernhardson: No worries. If you define a dependency inside <dependencies> and it lacks a <version> POM will complain. However, if a <dependency> with matching group/artifact-ID (and <version>) exists within <dependencyManagement> it will resolve the version from it.
[16:56:44] <pfischer>	 Same goes for plugins. Furthermore, plugins can be configured. Here the cascade looks like plugin default (defined by authors) <- plugin in management section <- plugin in plugins section
[17:00:14] <ebernhardson>	 pfischer: ahh, ok that makes sense i suppose. I suppose i still don't quite understand how all these fit together, but getting there :)
[17:02:34] <ebernhardson>	 in this case i'm trying to generalize our scala deps/build steps/test frameworks/plugins  out from individual poms into a project we have called discovery-parent-pom, which is generally the parent to all other projects. Might have finally gotten it to work (`clean verify package` without failure) but had to add some scopes into the parent-pom which i was expecting to only need in the
[17:02:36] <ebernhardson>	 final package
[17:02:37] <pfischer>	 ebernhardson: Ah, I think I know what you mean by ignoring in regard to effective pom. So the effective POM should not require such resolving as this has already been done (therefore effective).
[17:03:42] <ebernhardson>	 i suppose i was trying to avoid it because there is a comment in the parent pom `Unless necessary, <scope> should not be specified in this parent pom.`
[17:04:00] <ebernhardson>	 i suppose i'm still figuring out what necessary means :)
[17:04:44] <pfischer>	 Hm, maybe because it narrows down the matching (group + artifact ID + scope) instead of (group + artifact ID)
[17:05:13] <ebernhardson>	 oh! that hadn't occured to me, for some reason i thought that meant it would enforce the scope on places that use it
[17:05:29] <ebernhardson>	 being part of the matching rules makes a bit more sense
[17:07:04] <pfischer>	 Depends on where de <dependency> resides. Under <dependencies> it would be copied to all children. Under <dependencyManagement> it would be used to resolve (versions) if any child references the <dependency> in its <dependecies> section
[17:08:26] <inflatador>	 sorry, been back
[17:08:54] <ebernhardson>	 pfischer: thanks! that does clear a couple things up.  I'm mostly over here guessing and reading verbose docs that don't seem to say very much like https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
[17:09:59] <ebernhardson>	 pfischer: i suppose i should also mention, it's probably late in eu and no need to spend extra hours on us :) I tend to rubber-duck into this channel with thoughts as I work, sometimes i even get responses but not required :)
[17:11:05] <ebernhardson>	 (but also you can work whatever set of hours works well for you, if working into the evenings and not working earlier in the day works for you, thats fine)
[17:11:47] <pfischer>	 No worries, I’m happy to help. :-)
[17:42:54] <inflatador>	 lunch/errands, back in ~45
[18:29:14] <RhinosF1_>	 welcome pfischer 
[18:38:07] <inflatador>	 back
[19:06:29] <inflatador>	 I'm pretty wiped out. Going to nap for an hour or so
[19:06:50] <ebernhardson>	 seems to be a consistent theme of recovering from covid, take the time you need
[19:22:13] <RhinosF1>	 Get well soon inflatador
[19:29:43] <ebernhardson>	 magic, always fun! GenerateEntityDiffPatchOperation.scala:227: local val in method createSerializer is never used
[19:30:43] <ebernhardson>	 of course there is no createSerializer method there, it's a one-line object with a single val used in the related class
[19:32:46] <ebernhardson>	 looks like it's related to generalizing the scala-maven-plugin now providing -Ywarn-unused to streaming-updater-producer, will have to figure out how to not provide that for now
[20:58:21] <inflatador>	 Thanks all! Back
[21:26:53] <ebernhardson>	 school run, back in a bit
[22:00:01] <inflatador>	 I'm headed out, have a great weekend all!
[22:16:44] <ebernhardson>	 back