We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Modernizing mesa3d.org

00:00

Formal Metadata

Title
Modernizing mesa3d.org
Subtitle
Let's bring mesa3d.org past web 1.0
Title of Series
Number of Parts
490
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
mesa3d.org is stuck on web 1.0 technology, but let's see what we can do about it. This is a Birds-Of-a-Feather session, which starts off with a short presentation as an introduction about the current state of affairs.
33
35
Thumbnail
23:38
52
Thumbnail
30:38
53
Thumbnail
16:18
65
71
Thumbnail
14:24
72
Thumbnail
18:02
75
Thumbnail
19:35
101
Thumbnail
12:59
106
123
Thumbnail
25:58
146
Thumbnail
47:36
157
Thumbnail
51:32
166
172
Thumbnail
22:49
182
Thumbnail
25:44
186
Thumbnail
40:18
190
195
225
Thumbnail
23:41
273
281
284
Thumbnail
09:08
285
289
Thumbnail
26:03
290
297
Thumbnail
19:29
328
Thumbnail
24:11
379
Thumbnail
20:10
385
Thumbnail
28:37
393
Thumbnail
09:10
430
438
CollaborationismBitView (database)Projective planePresentation of a groupComputer animation
Open setWebsiteHome pageMobile WebWeb browserMarkup languageElectric generatorFluid staticsWeb pageCollaborationismMereologyNetwork topologySource codeRepository (publishing)Computer fileBinary fileProxy serverProcess (computing)Instance (computer science)Boilerplate (text)Software repositoryHome pageWebsiteShared memoryBinary fileWeb pageMarkup languageBitSource codeInformationBranch (computer science)Web browserScripting languageContent delivery networkNetwork topologyContent (media)Link (knot theory)Projective planeFlow separationSet (mathematics)Distribution (mathematics)Fluid staticsFile formatRight angleRepository (publishing)Raw image formatInheritance (object-oriented programming)Point (geometry)Revision controlWeb 2.0Goodness of fitServer (computing)Electric generatorReading (process)Instance (computer science)Proxy serverControl flowMereologyBoilerplate (text)SpacetimeComputer animation
WebsiteMarkup languageProcess (computing)Open setWeb pageInstance (computer science)Boilerplate (text)CollaborationismSoftware repositoryWeb browserHome pageMereologyFluid staticsInformationMathematicsEmailLink (knot theory)BitWebsiteWeb pageMultiplication signHome pageMereologyComputer animation
CollaborationismWebsiteRevision controlOpen setScripting languageIntegrated development environmentRevision controlBitLink (knot theory)InformationSlide ruleProper mapWeb pageWebsiteComputer animation
Uniform resource locatorReverse engineeringProxy serverOpen setFile Transfer ProtocolContent delivery networkHome pageWeb pageKernel (computing)1 (number)Scripting languageUniform resource locatorControl flowProper mapFile archiverLink (knot theory)Process (computing)Web pageKernel (computing)Software repositoryReverse engineeringProxy serverComputer animation
CollaborationismBitContent (media)System administratorMultiplication signPoint (geometry)Similarity (geometry)Decision theoryReverse engineeringKernel (computing)Uniform resource locatorComputer fileLine (geometry)Survival analysisProxy serverFile archiverFile formatFreewareDrop (liquid)Goodness of fitControl flowComputer animation
CollaborationismMultiplication signQuicksortWebsiteCodeComputer animation
CollaborationismWeb pageRevision controlHome pageMereologyInformationWebsiteMarkup languageProcess (computing)Open setInstance (computer science)Boilerplate (text)Software repositoryWeb browserComputer animation
Home pageOpen setFluid staticsMereologyInformationCollaborationismBitWebsiteComputer animation
Open sourceImplementationLibrary (computing)Web pageHome pageOpen setGraphics libraryMaxima and minimaExecution unitNormed vector spaceVacuumSet (mathematics)Computer hardwareImplementationRule of inferenceOrder (biology)Electronic mailing listString (computer science)Device driverExpected valueStandard deviationCodeSoftware maintenancePhysical systemForcing (mathematics)Content (media)Mobile appFile systemProjective planeWebsiteComputer animation
Transport Layer SecurityCore dumpGraphics librarySource codeImplementationPhysical systemUser interfaceWebsiteSoftware developerFlow separationVapor barrierInformationTerm (mathematics)MathematicsDirectory service2 (number)Context awarenessDevice driverInsertion lossPerspective (visual)Content (media)Instance (computer science)BitWeb pageImplementationOcean currentAsynchronous Transfer ModeBuildingLink (knot theory)MereologyShader <Informatik>Data structureCodeGoodness of fitComputer animation
Point cloudFacebookOpen source
Transcript: English(auto-generated)
All right, I guess we can just get started. So hi again, it's me again. 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 kind of a discussion, but I have a little bit of a presentation to begin with to kind of 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 written in HTML 4.4.0.1, mobile phones didn't have browsers back then. If you ever try to go to mesa3d.org on your phone to kind of read some documentation maybe while you're on the train, it's not fun.
This is kind of what started my edge 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 kind of the mesa website
is 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. And we have static site generators and GitLab pages
and GitLab CI and stuff like that and free desktop.org that we can use. And I think kind of the thing that whenever I dig into this bothers me the most is that we're kind of like thrown all of the web presence stuff on mesa into one bucket
and kind of start it around. And we're getting like a website that's kind of a jack of all trades, master of none. It's not a great homepage. Like if you want to read about mesa, it's kind of like off-putting. You don't like, you have to dig for the right information. As a documentation, this documentation is kind of bad
because you have to, like 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.
Yeah, and then the releases are just kind of like in a subfolder on the same site there. And you don't get any good CDN or distributions around the world for the releases either. So it's kind of like it's not great at either of the things.
So my proposal is to split it into three different sites. One is the homepage. That would be mesa3d.org. This is where you go to kind of read about the project. It should be built, I think, using a static site generator like Jekyll or Hugo or, you know,
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 homepage 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 documentation, all of these things.
Then the documentation, I suggest having as a separate site, something like docs.mesa3d.org. We should build this using a, 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. And 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, wanna move the website 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 and 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 move, like stop uploading where we upload and move to somewhere else.
The problem with moving is that we don't wanna break links, we don't wanna break current build scripts. So I think we need to, at least for some time, live with a reverse proxy on top to get the links to keep working.
Yeah, so the benefits here are that we can now, once we split it like this, we can build a kind of flashy marketing site or like for the homepage, where you can like read about the project, kind of stuff like that. And it can be like a practical, you can have a practical and clean documentation site.
So you kind of like separate between what's like attention grabbing and what's kind of like pushing the information and kind of first and foremost. Yeah, and then we kind of get away from the whole jack-of-all-trades, master-of-none shenanigans that I think we currently do.
We can, yeah, edit the documents in like some sane markup language instead of raw HTML. And right now we have the same HTML boilerplate repeated in every document. So if you ever wanna change the detail about that boilerplate right now,
yeah, it's not great. It's super painful. And I think we can, 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 patches, but it's not really documented on the website. You don't know, like if you go to mesa3d.org, you have no idea that this is actually the docs folder of the website. So we can 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 kind of what it looks like. It's not a fantastic website, but it's kind of what I was able to clobber together. It's built using Jekyll and Bootstrap, and I made a custom, so it's not using any of the kind of built-in themes
because I wanted to have a little bit of familiarity with the old website. So you kind of like recognize a little bit that you're at the mesa 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 works really nicely on phones. It builds HTML on the CI using GitLab pages. And yeah, it contains only the kind of the static parts about mesa, so stuff that doesn't change with every release.
Yeah, and it also provides, yeah, the news are actually, like if you go to mesa3d.org right now, you 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 paginated 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 if you hover them. So yeah. So yeah, so this is kind of my proposal for the website.
Here's kind of my proposals for the doc site. This builds the documentation. So this converts the documentation to Sphinx, and it's, yeah. The link is actually the wrong one. I'm sorry. They 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 mesa3d website with this Sphinx site. I wasn't a big fan of that,
particularly 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 mesa logo and stuff like that, and I kind of,
this gets very opinionated, and people have different ideas. Sphinx doesn't handle pagination at all. So the news page was still like miles long, scroll forever kind of thing.
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. 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 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 mesa 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 mesa3d.org slash archive link, which is what requires the reverse processing 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 at, well, keep it there, but reverse proxy this URL
and have that hosted separately from the GitLab pages. So we keep the old website, 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 mesa,
so we don't really have a huge load, I think. But both the kernel and gnome has proper CDNs, 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 infer this. Yeah, sure. The problem to me is not so much the,
if you know for 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
as opposed to contributing to mesa, because currently I think the wrap-up is huge. Right, so what he's saying, if someone didn't hear, is that the problem right now for many people are, or at least were for you when you got introduced to mesa,
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 gonna happen, but I hope so. The first time we see such effort or such drive, and definitely I think it's not the last, how exactly are we going to pursue to get home 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 wanna, of course, have everyone be able to see what they think, say what they think about it first. I don't wanna 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 troubles without breaking the road for everyone. That was pretty much the last issue. Once we figure out a 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, kind of 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 kind of 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,
could you use the pipeline to generate the files and just drop it there at the current location? We could, yes, we could. So no reverse proxy extra needed and just have it filled? Yes. 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 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. I was gonna say something similar to what you were saying about the beginners getting started.
When you showed a shot of your homepage, which did seem to fall into the same trap that I found a lot of websites do, like, for example, when Rust changed their homepage, 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, what 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 have to be same, it'd be just that it's itself. And yours, as well, there, has, like, a basic introduction and latest news. So I, yeah, I think, so I'm gonna just pull up the site here, so I can,
oh, shit, I don't, I'm not on any sort of WiFi here, I guess, yeah, so. But you can file issues, you can do all this and this,
but if you're a brand new user, you're not gonna want to. Yeah, so I show kind of, like,
which APIs are there and stuff like that. I'm not entirely sold 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 that kind of intro bit at first. The read more stuff takes it to the documentation site, to the introduction article there, which is the old, well, yeah, it, 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 gonna, oh, this is, this is not great, but okay.
Yeah, all right, so this isn't my, my desktop and 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's provides of APIs.
Yes, I know. This, like this is a mock-up. If we remove stuff, we remove stuff. Like this isn't, I don't mean for, like I don't mean for any of the content here to be final. I'm totally open for, you know.
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 rules here, but I think we should ask Kronos what they think. Kronos is pretty friendly to the Mesa project.
So I'm not, like, I'm not too worried if there's a logo we need to remove. Like some of these things don't really have logos. For OpenCL, I really didn't want to use their horrible logo anyway, because it's like looks so different and it kind of, yeah, it's, yeah.
I mean, we could just like write under the feature APIs there. Like note, some of these are not implemented for all hardware and stuff like that. Yeah, 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.
So I'm, this is not all of the drivers. It's, 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 sets 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. 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 have a question kind of for the audience here. And so a couple of people mentioned things like having a code on the website to show you how to use it and everything. But MISA is just an implementation of a bunch of standards.
We don't really, we're not there to show you how to use GL and all of them. We're kind of just providing a lift that allows you to do that, so. Yeah. I was going to say, that was just an example from the Rust website, they used to have code. Yeah, yeah, but what is the kind of thing that you would want to see on the website?
Well, you can do the getting started thing. But the getting started on what? Because to me, MISA is kind of just a leave that you compile and install on your system and that's it. Then you use your app normally, or you write an app. Then that's what API you want to use for your app.
So don't really understand what it is that you want to see. So that's my question. This might be a bit tangential to MISA itself, but using cases, for example, that are uncommon, like using EGL in context of KMS and DRM, which doesn't really exist, you could hunt down that information. Whereas using EGL GLX in context of X
is easy to find files. That's just not there, for example. That would be one thing, these introductions to that. For people who want to get started hacking on MISA itself, introductions to its structure, how it works, bits of code you could possibly hack on
and modify to see how it affects MISA's implementation so people can poke it 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're 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.
Yeah, so from a kind of perspective of what I've shown here, I think like, 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. It's gonna 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 like 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 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 Kugo 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 like 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 does incremental builds. Yeah, but incremental builds, like if you change the template, then it builds all of the pages. And it kind of like 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 okay. 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 would be my next thing to try. I've used Jekyll a little bit. I get very confused by Jekyll. 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, maybe. So as I said, I 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.
Yeah, 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, yeah.
Seems like the discussion is over, yeah. All right, cool. Thanks a lot.