00:54 <xorgy> 01:58 < alanc> many would argue new usage should be using libwayland-client, not libX11 or libxcb << I'm one of those people whose workflow is still very broken under Wayland

00:55 <xorgy> (and also I was a Wayland early adopter)

09:48 <pq> What's preventing from just adding dcz_ to the ci-ok list?

09:53 <pq> fomys, #dri-devel is a better place to ask about dim etc.

09:57 <fomys> pq: Thanks! So I'm moving my question

09:58 <pq> fomys, also congrats(?!) for the maintainership! :-)

10:02 <emersion> pq, nobody is directly on the CI-OK list rn

10:02 <emersion> iirc bentiss wanted to keep it that way

10:02 <fomys> Thanks!

10:02 <fomys> I hope I will be able to merge the YUV series soon : )

10:02 <fomys> I have some feedback to address from Maxime, but the first part (rework the composition algorithm) is fully acked-by by Maíra

10:02 <fomys> And I am working with José on the ConfigFS configuration, and now MST emulation (currently nothing works, but I made some progress)

10:03 <dcz_> btw, I have set up a crappy runner for myself, but I think what I'm really after is the legitimacy of the project being in fdo

10:03 <bentiss> pq, emersion: yes, I'd rather not have a global list of individuals vetted by a couple of admins when we can have each group responsible for their users

10:04 <dcz_> otherwise, fdo has a long user approval and gitlab is rather slow, so I worry about losing potential contributors that way

10:04 <dcz_> *its gitlab is rather slow, compared to other instances

10:06 <bentiss> regarding gitlab being slow, yes, we know, it's both a lack of resources (because we are hosting heavy projects) and historical reasons because we are using kubernetes, though k8s saved us a fair bit of time

10:07 <bentiss> regarding "long user approval" not sure what you mean. During the week, it shouldn't take more than 24h, usually less than an hour. During weekends, .. well, we also have a life

10:09 <dcz_> I don't blame you, just explaining my reasons. Comparing to github, 90% of people don't need a new account to contribute, gitlab.com registers in 10 minutes. That heavily depends on what kind of contributors I'm going to have though

10:09 <dcz_> (also the reason I'm not considering codeberg although I love the concept)

10:11 <bentiss> if we had an efficient way of detecting spammers and script kiddies, we could return back to the "no restrictions" time, from a few years ago, but right now, some people ar abusing our system, so we have to take defensive actions, unfortunately

10:11 <bentiss> (and we don't have an army of people monitoring spam)

10:12 <dcz_> I totally get it, and I am disappointed the cards are stacked against you. Still, I want to choose what lets my project take off

10:14 <dcz_> so having a label of "official fdo project" is probably good enough, but I don't know if "private project on fdo" is

10:18 <bentiss> probably not. I just prefer not being the one taking the yay or nay decision on which projects gets accepted

10:18 <fomys> bentiss:Do you have a really small infrastructure for the number of projects or is it the whole gitlab that becomes very slow when there are big projects? For example, clicking on ‘edit profile’ (i.e. unrelated to a project) takes more than 10 seconds (I'm not blaming anyone, it's already a huge job to have this instance running and to manage it, I'm just asking the question out of curiosity).

10:19 <bentiss> fomys: we only have one replica of the db, so if we have heavy db tasks, everyone is seeing that

10:19 <hakzsam> so, is the branchpoint delayed?

10:20 <bentiss> the problem is partly the numbers of disks for replicating the db: our db is in the 300GB range, but with ceph it's replicated on 3 disks, so that's ~1TB per instance. and because we want to keep them running on SSDs, we don't have enough space to duplicate it twice :(

10:21 <bentiss> the plan was: split the db into CI + rest (was part of 17.0, but we got some big issues when we tried it), and then try to duplicate the main db

10:23 <bentiss> anyway, I don't have enough time to sink into that, and that's one of the main issue (plus I'm not a DB expert at all)

10:24 <fomys> bentiss: I see, thanks!

10:54 <pq> emersion, hmm, I thought I was. Oh well.

10:59 <pq> dcz_, sounds like you need to be accepted to any existing gitlab.fdo group with CI privileged, then you can run CI on any project you like. Mesa, Wayland, something else?

11:04 <pq> hmm, surprisingly hard to find gitlab.fdo docs by starting from https://gitlab.freedesktop.org/

12:41 <karolherbst> maybe we should have a "fdo approved project" stamp 🙃 then we can just tell people to host on gitlab.com/github lol

12:42 <xorgy> not a silly idea

12:42 <xorgy> FDO gitlab shudders and coughs every time I add an emoji reaction

12:42 <mripard> karolherbst: a crappy mp3 on autoplay saying "I'm fdo and I approve this project" ?

12:42 <karolherbst> something like that

12:43 <karolherbst> one of those 90 themed gifs maybe

12:43 <karolherbst> *90s

12:43 <karolherbst> ehh wait

12:43 <karolherbst> yeah..

12:43 <xorgy> if people have trouble reading it, they can read alt text...

12:43 <karolherbst> like

12:43 <karolherbst> early internet day gifs

12:43 <karolherbst> but yeah.. there are no great solutions here

12:43 <karolherbst> our CI stuff is super heavy

12:44 <karolherbst> sooo.. maybe having somebody familiar with the db split to help out on the next update could help? dunno

12:44 <karolherbst> it's still tbd how much that would help with

12:44 <karolherbst> but having a database expert helping out here would probably help a lot