 All right, I guess we can just get started. So, hi again. It's me again. When I'm not working on, so I like to work on pretty technical stuff, but every now and then I need some lighter work to do. So, one of the things that one of my pet projects to work on when my brain is hurting, is to look into trying to get the Mesa website, make it a little bit better than what it is now. So, this is not meant to be a talk, this is meant to be just a discussion, but I have a little bit of a presentation to begin with, to present my view of things and what can be done better, and have some proposals and stuff like that. So, for the first thing to talk about is what's wrong with Mesa3D.org right now, it's a pretty old website. It was written 15 years ago, kind of the current version of the web part of it, not necessarily the content. It's like written in HTML4.401, it's mobile phones didn't have browsers back then, if you ever tried to go to Mesa3D.org on your phone to read some documentation, maybe while you're on the train, it's not fun. This is what started my it share, I wanted to check some stuff while I was on the bus, and yeah, it wasn't very fun. So, now we're 15 years later, and the world has changed quite a bit. We have HTML5 now, and translating the Mesa website to that is a little bit of a pain. We have better markup languages and tools for dealing with this. Maybe some of this was already around back then, but not quite as popular and adopted. We have static site generators and GitLab pages, and GitLab CI and stuff like that, and on free desktop.org that we can use. I think the thing that whenever I digs into this, bothers me the most is that we're thrown all of the web presence stuff on Mesa into one bucket and started around, and we're getting like a website that's a jack of all trades master of none. It's not a great home page, like if you want to read about Mesa, it's like off-putting. You have to dig for the right information. This documentation is bad because if you're reading the entry stuff, you have to open it in a browser to read it in a reasonable way. The raw HTML isn't fun to read. We keep updating it with the broken HTML stuff, because HTML is hard. Then the releases are just in a sub-folder on the same site there. You don't get any good CDN or distributions around the world for the releases either. So it's not great at either of the things. So my proposal is to split it into three different sites. One is the home page that would be Mesa3D.org. This is where you go to read about the project. It should be built, I think, using a static site generator like Jackal or Hugo or it's not really important. Just the important bit is that it's easy I think to read and edit and work on. It should probably live in a separate repository from the website, because I think the home page shouldn't really contain things that pertain to the source code. That's for the documentation and for what you get once you download the source code. It should contain stuff like where do you download it? Where do you go for filing issues? Where do you read the documentation? Yeah, all of these things. Then the documentation I suggest having as a separate site, something like docs.mesa3d.org. We should build this using from CI, from the master branch or release branch of Mesa, using Sphinx or Gitbook or one of those more modern documentation tools. This means that we can actually read the entry sources in a reasonable way on a human readable market format. Yeah, releases. I don't really have a great answer to. It's a little bit of a pain. So GitLab pages which we ideally, I think, want to move the websites into being hosted at, doesn't deal great with a large set of static binary files. You have to upload them for every build of the site. You have to copy them into the sets of stuff. Yeah. So I'm wondering if we should have just keep a separate web server instance running and use some reverse proxy to put it in the right space, or we stop uploading where we upload and move to somewhere else. The problem with moving is that we don't want to break links. We don't want to break current build scripts. So I think we need at least for some time, live with a reverse proxy on top to get the links just to keep working. Yeah. So the benefits here are that we can now, once we split it like this, we can build a flashy marketing site for the home page, where you can read about the project stuff like that, and you can have a practical and clean documentation side. So you separate between what's attention grabbing and what's pushing the information first and foremost. Yeah, and then we get away from the whole jack-of-all-trades most of non-genonians that I think we currently do. We can edit the documents in some same markup language instead of for HTML. Right now, we have the same HTML boilerplate repeated in every document. So if you ever want to change a detail about that boilerplate right now, yeah, it's not great. It's super painful. I think the last point here is like, I think we can move to something that's a little bit less opaque because right now, it's not really obvious to figure out how to change the website. Like, yes, there's documentation. It's all in the tree there. You can submit the patches, but it's not really documented on the website. You don't know. Like, if you go to messathreader.org, you have no idea that this is actually the docs folder of the website. So we could put like an edit this page, for instance. There's more, I think we can work more on this process there. So here's my proposal for a new homepage. So I've built this site. This is what it looks like. It's not a fantastic website, but it's what I was able to clubber together. It's built using Jekyll and Bootstrap, and I made a custom, like so it's not using any of the built-in themes because I wanted to have a little bit of familiarity with the old website. So you recognize a little bit that you're at the messa website. So the little gears in the corner there and like a dark header with a white background. It's mobile friendly. I don't show this here, but it reads like works really nicely on phones. It builds HTML on the CI using GitLab pages. Yeah, it contains only the static parts about messa, so stuff that it doesn't change with every release. Yeah, and it also provides the news are actually, if you go to messathreader.org right now, you'll get all news since the beginning of time in one long page. This actually gives you just like the latest ones. There's a link here to reading all of the news, and that's a page-nated page. So you get like 10 news entries at the time and you don't have to load stuff from the mid 90s and stuff there. The gears turn. The gears turn if you hover them. So yeah, so this is my proposal for the website. Here's my proposals for the doc site. This builds the documentation. So this converts the documentation to Sphinx and the link is actually the wrong one. I'm sorry, we should just remove intro.html. I changed that since I wrote the slides. This effort was started by Laura Abbott. She wrote some scripts to automatically convert. I've updated them a bit and fixed up some things. When she worked on it, she was trying to replace the whole messathreader website with this Sphinx site. I wasn't a big fan of that particular because of the news. So there's two things. One is that branding of the website was kind of important when it's the website. So there was some debate back and forth about making a proper messa logo and stuff like that. And I kind of, this gets very opinionated and people have different ideas. And Sphinx doesn't handle pagination at all. So the news page was still like miles long. Scroll forever kind of thing. So and as far as I could see, I tried for a while to find something for Sphinx for this. It doesn't really seem to exist. I guess I could have patched it, but I thought just, hmm. Yeah, yeah, yeah, you're right. My bad. Yes? Yes, yes, you're right. My fault, my apologies to both of them for getting the wrong person there. Yeah, so yeah, this also does like the CI dance to convert stuff. As a kind of nice added benefit, we could move it to host the stuff on the readthedocs.org infrastructure. They have some nice bells and whistles where you can have multiple versions of the docs. So you can actually check the version of the docs that matches the version of messa you have. This is interesting kind of because you sometimes change the environment variables. And if you're stuck on like an LTS release of something, it's kind of annoying if the wrong information is there. Yeah. And then finally for releases, yeah, that's the current situation is that we're hosting these releases in three different URLs, one over HTTPS. So the nice thing is that it seems we have almost forever advertised the top link and the top two ones only. So none of these are under or none of the first two ones are under the main repo. So maybe we're lucky and no one actually has a script where it downloads it from that unadvertised messa3d.org-archive link, which is what requires the reverse proxy thing I talked about before. This needs some, I think, we need to do some logging and stuff to figure out if that is the case or not. Yeah. And changing it, as I said before, we'll break these URLs if we move it. So my best proposal, I think right now, is just to kind of keep it there but reverse proxy this URL and have that hosted separately from the GitLab pages. So we keep the old websites but kind of delete the page and do some redirects there and it's easy. We could also use a proper CDN but I'm not really sure if we care about that because I think most people use distro packages for messa3d so we don't really have a huge load, I think. But both the kernel and GNOME has proper CDN so we could also maybe piggyback on those. Kind of just start going there. I'm getting a signal that is 15 minutes left. I don't think that's true. All right. Yeah, so this is pretty much all I have. Now I want to hear if anyone has any ideas or suggestions on how we can improve this. Yeah, sure. The problem to me is not so much the HTML4 or whatever page. The problem is more the content. So the content is really not geared toward people who are unfamiliar with the topic. And that's really the more urgent thing to really make it that people can contribute or start contributing to messa3d. Because currently I think the wrap-up is huge. Right, so what is saying if someone didn't hear is that the problem right now for many people or at least were for you when you got introduced to messa3d was not so much the packaging but more of the content. And I agree that the content isn't great, but I hope that making this into a easier to edit format will make it a little bit less painful and kind of will incentivize people to keep things more up to date. But that remains to be seen, I think. I think it's hard to say that that's definitely going to happen, but I hope so. This is not the first time we see such a forward or such a try. And definitely I think it's not the last. How exactly are we going to pursue to get forward this time to make this happen? Well, so yeah, so if someone, I think everyone heard that. Yeah, so how we get this to happen, I think. I'm not, so I'm the only one, like I'm working on this kind of alone, but I'm kind of a little bit talking with some of the free desktop admins and stuff on the side. So I think there's more people who want this. And I think we just, at some point, need to make a community decision and kind of move forward. And I think I hope that this is, like what I'm presenting here, is enough to move forward. But I want to, of course, have everyone able to see what they think, say what they think about it first. I don't want to break anything for anyone. So I've been following that for a bit as well. And I think everybody agrees on the idea of doing that. Basically, the only thing that was preventing it was the technical issue of the archive and how to actually keep providing the problems without breaking the rule for everyone. That was pretty much the last issue. Once we figure out the good solution for that, I think everybody agrees on how to actually do the rest. Yeah. And just to fill in on that, the free desktop admins that I'm talking to, mostly Daniel Stone, is really not happy about the idea of having to maintain a reverse proxy for a long time. I totally understand that. But I think right now, the situation is kind of similar anyway, because there's already a reverse proxy for this. I think it's mostly a matter of reconfiguring what we have and kind of turn on some logging and make sure that we know if someone keeps using these old URLs, and maybe we can turn it off a couple of years down the line. The kernel moved all their releases with, I think, six months notice and just removed the old URLs. And the world survived. We could also just say it's not that important. Like, people have some time for themselves. I don't know. Since you use GitLab now, couldn't you use the pipeline to generate the files and just drop it there at the current location? We could, yes. So no reverse proxy extra needed, and just have it built when master commits come in, maybe every day? So the goal is kind of to find a way to avoid having to deal with this. But yes, we could untangle all these things and solve one problem at a time. I think this is a good excuse for trying to solve both, though. But maybe not. So I was going to say something similar to what you were saying about the beginner getting started. And you showed us sort of your home page, which did seem to fall into the same trap that I've found a lot of websites do, like, for example, when Rust changed their home page, one of the major criticisms was before it was like, you got there, and the first thing you saw was a piece of Rust code showing exactly what it did or the advantages were. And then now that they've changed it, it's basically become almost for managers saying just like, it's better, it's faster, use it. But it doesn't actually say anything about it itself. And yours as well, there, had basic introduction and latest news. So yeah, I think, so I'm going to just pull up the site here, so I can, oh, shit, I'm not on any sort of Wi-Fi here, I guess. Yeah, so yeah, so I show kind of like which APIs are there and stuff like that. I'm not entirely solved of whether or they should be collapsed or not by default. But for mobile, it's actually much nicer to not get a wall of stuff before you get the news. Maybe we could reorder it to do that or something like that. But I think it's nice to have the intro bit first. The Read More Stuff takes you to the documentation site, to the introduction article there, which is the old, well, yeah, the old website takes you directly to the news. That's the only thing you see to begin with. So I think, so I'm going to, oh, this is not great, but OK. All right, so this isn't my desktop system being high DPI here. Yeah, so kind of like this is more of what I kind of envision. It's looking like on desktop at least. So you kind of like get here and you immediately see kind of what it provides of APIs. Yes, I know. Like this is a mock-up. If we remove stuff, we remove stuff. I don't mean for any of the content here to be final. I'm totally open for, you know. Yeah, so I don't think. So I don't think these things says that we're conforming for all drivers. I don't think we violate the Kronos kind of trademark rule, sir. But I think we should ask Kronos what they think. Kronos is pretty friendly to the Mesa project. So I'm not too worried if there's a logo we need to remove. Some of these things don't really have logos. For OpenCL, I really didn't want to use their horrible logo anyway, because it looks so different than it's kind of, yeah. Yeah, I mean, could we just write under the feature APIs there, like note, some of these are not implemented for all hardware and stuff like that. Maybe something that would be a good idea to kind of lower expectations a bit. Yeah, so there's like a list of drivers here also. This is not all of the drivers. I'm not sure if we, I don't know. I don't love this. This is like one thing that I don't love about this is it kind of forces us to order all the drivers. So I kind of like, instead of having to choose an order, I just like these are sorted alphabetically. The order, we get it out of the file system like when we iterate over the data set in Jekyll. I don't know. Also, I think these strings are probably wrong for a bunch of them. And like I think all of the driver maintainers should go through each of the strings here and verify that they're reasonably correct. Could be X. Yeah, yeah, I think so. I think that was, this would be a good place to put the mesometrics as long as we can find a way of reasonably integrating it into the build pipeline. But I'm sure we can. So I had a question kind of to your audience here. And some of the people mentioned things like having a code on the website to show you how to use it and everything. That means that it's just an implementation of a bunch of standards. We don't really, we're not very sure you have to use GL of open. We're kind of just providing a lift that allows you to do that. So yeah. That was just an example from the REST website. They used to have code. Yeah, but what is the kind of thing that you would want to see on the website? Well, you could look at getting started, I think. But you started on what? Because to me, MISO is kind of just the lift that you compile and install on your system and that's it. Then you use your app normally. Or you write an app, but then that's what API you want to use for your app. So I don't really understand what it is that you want to see. So that's my question. This might be a bit tangential to MISO itself. But using cases, for example, that are uncommon, like using EGL in the context of KMS and DRM, which doesn't really exist, you have to hunt down that information. Whereas using EGL GLX in the context of X is easy to find piles. That's just not there, for example. That would be one thing, I think, these introductions to that. For people who want to get started hacking on MISO itself, introductions to its structure, how it works, bits of code you could possibly hack on and modify to see how it affects MISO's implementation so people can look at and see how it wobbles kind of safely. So what if I mess with, I don't know, the Shader Compiler? Let me make it do something. That kind of thing. Because really, that's the implementation. Mostly, that's what you want people to start learning and figuring out. I think you need separate introductions for users and developers. Like, have it split. Have it split like, hey, if you're a user, go here. These are the drivers you are looking for. And you can install it through your distro. Hey, if you're a developer, go here, here are the docs. Start here. Yeah, so from a kind of perspective of what I've shown here, I think a lot of these things are kind of about which articles to have in the documentation, which I think is great to have more articles about more stuff. And we need to put that somewhere. I don't know if the website or the docs are best for every kind of article. Guessing probably the docs is going to be where you want most of this technical stuff. So I think for that stuff, maybe we just want some kind of visible link for the most important stuff on the website to where we can put stuff like that. I'm not really myself looking into writing a whole lot of content because it's not something I'm good at. I'm sorry. But yeah, I think there's a lot of stuff we could have better content at. And I think there's probably not enough people out there who's willing to contribute some of their knowledge if they know how and where. So it could be that making the barrier lower here might get us some more documentation. So I could mention something else. There's one thing that I'm not very happy about with the current implementation there. I used Jekyll to build the whole thing. And I pretty quickly stumbled into problems of performance with Jekyll. So I've been considering rewriting it using something like Kuba or a faster one. Yeah, the site generator. I think about 30 seconds on my laptop, which it's not horrible, but it's not great to kind of change one little detail and wait 30 seconds until. And it's also like. You can run live mode with Jekyll and that's fast. Because then it's just incremental builds. Yeah, but incremental builds. Like if you change the template, then it builds all of the pages. And it kind of just serves the old content until the build is done, which I think is not fantastic. So I think it's much better to work on than the current solution, but it's still not perfect. But I also think that maybe the websites don't need as much work on it as the documentation sites in terms of content. So maybe it's OK. I think it's for now I'm happier with this than the current solution. So I would be happy to move on with this and then look into performance later, for instance. Yeah, I think that that would be my next thing to try. I've used Hugo a little bit. I get very confused by Hugo. Feels like I'm too dumb for Hugo or something. But maybe I should give it another try. I've seen people rebuild Jekyll sites in Hugo with kind of getting the exact same sites. So yeah, I think the only thing is that Hugo is a little bit more insistent on having all of your content being like a tree. Yeah, it's like everything is like directories or nodes kind of, whereas in Jekyll it's all just pages and you kind of insert the links yourself. Like the relationship between the articles are up to the content and in Hugo it's kind of like part of the structure. Yeah, I've felt very stupid trying to use Hugo. I feel like I'm a little bit too dumb for it. So maybe there's something that I just don't get. So I got the message that we're 15 minutes left here. So yeah, and probably the next speaker wants to connect soon. So yeah. But if anyone has any more questions or ideas. Yeah, seems like the discussion is over. Yeah. All right, cool. Thanks a lot.