[09:10:32] Is there a surefire way to avoid having to de-merge-conflict changelog files on prod-image updates? I just spent an half hour fighting git and gerrit on this. [13:20:21] thanks elukey and klausman ... I'm all about making docs more dynamic. So if I can link to a dashboard or puppet code or whatever, I prefer to do that instead of hard-coding info if possible [13:23:32] inflatador: wrong chan :D [13:23:54] elukey LOL, they're right next to each other alphabetically [13:24:12] moving to correct chan.. ;P [13:25:33] inflatador: I did it a while ago, it happens when reviewing pings etc.. :D [14:16:06] follow up after yesterday's SIG: https://phabricator.wikimedia.org/T373526 [14:16:35] I noticed that Tobias already started it: https://gerrit.wikimedia.org/r/c/operations/docker-images/production-images/+/1046617/9/images/kserve/agent/control [14:17:17] let's try to assign a fair ownership of the images, shouldn't be strict but having a poc would be nice [14:17:31] tangentially related: T371549 [14:18:04] https://phabricator.wikimedia.org/T371549 this is about adding more metadata to the docker images, including ownership info [14:19:10] we discussed it yesterday yes! [14:19:21] elukey: yeah, I had wondered about individual ownership (as opposed to teams) before the SIG meeting. I think for some images it's very clear who's the main user of it (like kserve), but of course for others, it's a lot more fuzzy. [14:19:37] it is a good point, for production-images it would be nice to have a label coming from the "Maintainer" field in the control file [14:19:40] * inflatador also just saw the link to https://phabricator.wikimedia.org/T345070 [14:20:29] klausman: for the ML team there are a bunch: all the amd ones and knative-serving [14:21:11] stuff like coredns/cfssl/etc.. they may need to have a broad ownership, not sure if we could use the SIG as Maintainer [14:21:18] Ack. DSE might use some of them as well in the midterm, but ML being the first point of contact is probably beest [14:21:51] The SIG as first point of contact for the generic-ish/k8s-related stuff sounds like a good zeroth approach [14:22:15] klausman: definitely, do you mind to get your team's feedback about the ownership and change it during the next days? [14:23:45] will do, yep [14:24:33] super [14:25:10] same for all the others reading :) please review the list of the images with your team, and assign a team-specific ML where you feel that you clearly own the image [14:25:55] "own" == be a point of contact, not necessarily the only one allowed to work on everything related to a specific image :) [14:31:00] inflatador: what do you think about https://phabricator.wikimedia.org/T371549#10097016 ? [14:31:06] so we have a single task to work on [14:31:21] elukey works for me...feel free to merge/close [14:32:02] I guess the image attestation stuff is a little different, but that should be a different task regardless [14:32:43] inflatador: yes yes this is why I am asking - when you have a moment, if you want to add your ideas in the other task it would be great, so we have all in one place (then we can close) [14:34:25] elukey SGTM, I'll get to work on that [14:36:42] <3 [14:41:31] elukey: wrong phab task in your comment https://phabricator.wikimedia.org/T345070#10099843 [14:42:31] jayme: fixed thanks! [15:02:47] OK, closed T371549 with a link to T345070 and created T373530 just for the attestation tickets [15:04:20] side note, do we need to fix the bot that creates the phab tast links [15:19:58] inflatador: stashbot is not in this channel. It could be added if folks want it here. A task in https://phabricator.wikimedia.org/tag/stashbot/ would be appropriate to request that. [15:24:32] bd808: toolhub updated :) [15:27:35] elukey: excellent, thanks