13:30 <Consolatis> I'd like to raise a point about the CoC on FDO expanding outside of the platform itself. I know it is kind of annoying to deal with so I'll try to make it short.

13:30 <Consolatis> Also I am not quite sure where else to post this, this isn't exactly infrastructure but there doesn't seem to be another IRC channel that matches better. (And I am absolutely no fan of mailing lists, especially non-public ones).

13:31 <Consolatis> I actually *do* see the point of the CoC expanding outside of FDO for projects hosted at FDO. E.g, I write a shiny new $thing, host it at FDO and then link a IRC channel from the readme and that channel turns into some unmoderated harrasment crap. That could then indeed reflect badly on FDO. However, the recent situation felt very different, that was a single contributor to an existing FDO project who did not do anything against the CoC within

13:31 <Consolatis> the FDO infrastructure (that I am aware of at least) but got banned because of a immature response to a official warning from the FDO CoC team. That warning was about statements from 1 1/2 years ago in the discord instance of an unrelated project, hosted outside of FDO. I don't think that single contributors to existing FDO projects should even receive "warnings" for something they did outside of FDO and the projects hosted there. Ironically,

13:31 <Consolatis> that is something that makes me (and likely others as well) very uncomfortable. It also doesn't seem to be covered by the CoC in the first place. Some public discussion and self-reflection around this topic would be very interesting.

13:47 <privacy> I find the whole attitude of freedesktop.org tyrannical.

13:55 <pq> None of us outsiders have seen the whole story, so we cannot make judgment either. It looks what it looks like, but the CoC team has a hard time proving otherwise either, because providing evidence might look like libelling people, only making things worse.

13:57 <pq> We outsiders just need to trust the X.org board to scrutinize the CoC team actions. If you don't trust the X.org board, then you can think about how to fix that in the next elections.

14:16 <daniels> if you read what was actually said, it was: 'this stuff you're doing over in $veryrelatedplace won't be acceptable over here, just so you know'

14:17 <daniels> and the response was 'screw you, I'm not going to engage with you'

14:17 <daniels> if someone's demonstrating such active disregard for the CoC - and they are by refusing to acknowledge that it would ever be enforced - then that's not someone that I would want on fd.o, personally

14:18 <daniels> if fd.o CoC was some kind of tyrannical thought police who disappeared people without even the smallest thought for it, you'd be hearing about it much more often

14:18 <daniels> you can look at the CoC transparency reports (iirc in the XDC state of the foundation talks) to see how infrequently action actually gets taken

14:22 <Consolatis> <daniels> if you read what was actually said, it was: 'this stuff you're doing over in $veryrelatedplace won't be acceptable over here, just so you know'

14:23 <Consolatis> I am sorry, but based on the email pdfs I read that was *not* what was said

14:23 <Consolatis> it was more like if you continue to do so actions will be taken

14:23 <daniels> and?

14:24 <daniels> 'if you violate the CoC then we will enforce it with the documented consequences'

14:24 <daniels> I fail to see how that's a problem

14:24 <Consolatis> that is a very stark difference, your variant means behave on FDO space and the other means "we'll watch you wherever you are"

14:25 <emersion> there are a few other things to take into account here: one is that vaxry is a leader, thus they have additional responsibility compared to a random person

14:25 <emersion> another is that the communities are bound to interact with each other

14:25 <emersion> for instance let's say a hyprland community member reports a mesa bug, and a mesa dev joins the hyprland discord to debug

14:26 <Consolatis> and how does banning vaxry fix that?

14:27 <emersion> vaxry cuts communication with the CoC team, thus we have no way to enforce the CoC

14:27 <Consolatis> ^ I see the point there but then it should have been stated like that

15:25 <privacy> I find your arguments for censorship deeply flawed and wrong. I find your actions despicable. This whole org reminds me of a bunch of children fighting. See ya' later as I'm also choosing to end the conversation. Leaving channel.

15:26 <emersion> this is not a helpful comment

15:26 <Consolatis> no kidding :)

15:27 <f_> ?

15:28 <Consolatis> I assume you were referring to that "privacy" person, their comments in #wayland weren't exactly productive either

15:29 <f_> Ah, CoC stuff..

20:40 <alanc> is there another step I need to take to enable marge-bot for the xorg repos? https://gitlab.freedesktop.org/freedesktop/fdo-bots/-/commit/73121e76c976942ba2033c96b599ba29d63b1a09 is merged and I added marge-bot to the xorg group with Maintainer privs, but she doesn't seem to be touching https://gitlab.freedesktop.org/xorg/lib/libxshmfence/-/merge_requests/8 since I assigned it to her

20:41 <alanc> does some process need restarting to read the new config?

21:41 <bentiss> alanc: indead, it only looks for xorg/xserver. It's supposed to reboot itself on config changes

21:49 <bentiss> alanc: OK, should be fixed in a minute. This is unfortunately one of the few use cases where I need to manually push the change (because there is an environment variable to set on the container itself)

21:49 <alanc> thanks!

21:50 <bentiss> yep, I confirm, it's now pulling all of xorg for MRs

21:50 <bentiss> and it's on your MR now

21:50 <alanc> yep, just got the notice about marge rewriting the commit message for it

21:51 <alanc> and merged!

21:51 <bentiss> \o/

21:51 <bentiss> and sorry for not noticing it

21:54 <bentiss> hmm... that polling is taking quite some time (it looks for MR on every repo under xorg)

21:55 <daniels> yeah, there's a long-standing wishlist to do the search for MRs assigned to it, then filter by repo

21:55 <eric_engestrom> I don't have enough online time to do something about it, but the collabora farm seems in a bad shape with tons of jobs "running" (but actually "Waiting for job to start.") and making MRs time out

21:55 <daniels> rather than searching every repo for every MR then filtering for ones assigned to it

21:55 <eric_engestrom> eg. https://gitlab.freedesktop.org/mesa/mesa/-/jobs/57457506

21:55 <daniels> eric_engestrom: are you in a position to do the disable?

21:55 <daniels> if so, please do so with my Ab

21:55 <eric_engestrom> not really

21:55 <daniels> k

21:55 <eric_engestrom> well, no

21:55 <eric_engestrom> :]

21:55 <daniels> thanks for letting me know, I'll figure it

21:55 <eric_engestrom> thx

21:56 <daniels> weirdly it seems completely isolated to sona, despite having many separate machines across six separate dispatchers (thus having separate PDU/console/network/etc)

21:58 <eric_engestrom> I think DavidHeidelberg agrees with you: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28683

21:58 <eric_engestrom> anyway I'm out o/

21:58 <eric_engestrom> (and thanks DavidHeidelberg!)

21:59 <DavidHeidelberg> yup, sona is dead baby, long live to rest of farm...

21:59 <bentiss> alanc, daniels: so for marge for xorg, the polling time to look for every repo is ~9 min...

21:59 <bentiss> not sure I'll have time to work on this :(

22:00 <alanc> so I guess that adds an answer to "Why shouldn't marge just handle all of xorg/* ?"

22:00 <bentiss> that is one piece of the puzzle, yeah :)

22:01 <bentiss> we could reduce it to xorg/lib and xorg/xserver, maybe

22:02 <bentiss> anyway, not a big deal right now, I'm not sure it adds a lot of load on the server, but keep in mind that marge won't be fast at getting to its MRs

22:02 <alanc> still faster than any human reviewer handles xorg MRs

22:02 <bentiss> true :)

23:05 <alanc> The cert for bugs.freedesktop.org expired Tue, 26 Mar 2024 07:03:31 GMT