 Okay. So let's go. Hello. Thank you for being on my talk. As Paul said, there's always very nice talks competing on the same slot. So thank you for being here. I'm Albert. You can see my address there and my IRCNIC and Handel in most of the services out there is TSDGEOS. I know it's hard. Don't try to pronounce it. Just write it. Okay. So I cannot change the slides. I can change the slides. Good. So a bit of why I'm being a developer in KD since 2003. I'm very close to my 20th anniversary already. So that's a lot. Obviously, since I've been in KD for a long time, I've done a lot of things. Just a few things there to mention KPDF that later became ocular. I've been doing translations both translating to Catalan and as a co-coordinator with Luigi for the translators. I've been doing releases of KD gear and all the things that we named before KD gear that are the same thing. Work with games. Edu, I was the founding president of KD España, which is the local association for KD in Spain. I was a board member for the KDEV. So yeah, a bit of everything. Now, you maybe already know that. I knew that because I've been in KD for a long time and people meet me here. But this talk is also about Qt, right? So I need to speak about the Qt side. Qt is a bit more strict than us, KDE, while giving people committing powers. So you can contribute a lot of patches and still not get approval rights, which approval rights mean you can approve somebody else's patches, right? So I got Qt approval rights in 2018. But it's fine. I mean, I've contributed 400 patches, which, depending who you ask, might be a lot or might be not a lot. I think it's a good number. I don't feel like I've contributed huge amounts of code, but yeah. I know a bit how it works, so I think it's fair. So after the introduction disclaimer, this is my opinion, right? This is not KDE's opinion. This is not my employer's opinion. This is just my opinion, right? Because I mean, there's some things we're going to talk about, which are history, and history is more or less set in stone. So that's probably true, though it's always interpretable. But some of the things are going to be my interpretation on current events, right? So just to make it clear, this is just me. If you have to hate or flame someone, hate me. So a bit of history. I hope you all know Qt is this thing we use in KDE to do user interfaces, right? So it was introduced in 1996, and it used something called the Qt Free Edition License, which you cannot really distribute, so it made it not be free software, right? I'm going to do a small site here. If you're ever doing some software and you want to write a license for it, do not write a license for it. There's already a gazillion of licenses out there, so just pick one that really exists. Writing a license is very, very hard, so don't do it. Just reuse something. I'm 99.999% sure that there's a license out there that does what you want, right? So it was written by lawyers and all those people that know better than us, engineers, coders, whatever, what to do. So yeah, don't do that. Then it happened that KDE started using Qt, and KDE was so amazing compared to what there was in Linux before. People start to get worried, right? Because even though KDE was GPL, Qt wasn't, it wasn't even free software, right? So it was like, what do we do here? This is nice, but it's not nice because of the license. So the Qt people recognized that, and in 1998, they together with us, we created this thing called the KDE Free Qt Foundation, which is always a mouthful to say, right? And the first thing that the foundation is, which is very clear, is the purpose of the foundation is guaranteeing that Qt will be available for free software now and in the future, right? So that's what the foundation is about. The mandate of the foundation is making sure that happened, right? And then there's a few other clauses which are supposed to be a bit about getting the people that were developing Qt, which back then was Troll Tech. I didn't make a typo in the space. If you look at the announcement, there's a space there. I guess they changed their naming later because we're all used to getting Troll Tech written together, but the announcement was with a space in the middle. So it's not my fault. There's a few clauses there that say, well, I mean, you know, you have to release Qt every so often. And if you don't, it's going to be re-licensed. Well, the foundation will have the right to re-license and there is the license. There's a lot of legalese around that. But so that's a bit to make sure that Qt just keeps on developing and releasing a free version of Qt we could use. So moving a bit forward, there's this thing. And we were using, it was Qt1 and Qt2 and Qt3 and Qt4 and eventually Qt5, right? Well, they've done a Qt6 now, but let's not get affected of ourselves. So when they did Qt5, they realized that, well, I mean, this is going to be a biggest change. And you know, let's make Qt4.8 letting them support. So this way, we can have people stay in Qt4.8 for a while while we make sure that Qt5 gets mature enough and everything can be ported to it, right? And that does actually a very good idea. You can see that Plasma 5 was only released in 2014. So that's two years after Qt5, right? So there was a whole two years that Qt5 was already released. But Plasma, or whatever you would call it, KDE desktop back then. I don't remember Plasma 4 already, right? Yeah, Plasma was still based on Qt4, right? So it makes sense to be, to be having releases of Qt4 in case there's small bugs or whatever, right? So you can see that the last Qt4.8 release was in May 2015. So that's four years after Qt4.8. So that's a very good decision in my opinion from the Qt company. Well, not a good company. I don't know who was developing Qt back then. Probably still Traltek or Nokia. I don't remember. Anyhow, the people that were developing Qt, very good decision for them, making sure that we could use a stable Qt while we worked on the next version of Plasma that used the new Qt, right? So fast forward a bit more and we get Qt5, right? And Qt5, so in Qt4 they had never had the concept of long-term support until the last version, right? Until Qt4.8. In Qt5, they introduced the concept a bit more and every three versions after 5.6, you got a long-term support, right? So you got 5.6, 5.9, 5.12, and 5.15 as long-term support. Qt5.12, it's still supported as long-term support. There was a release in May this year. So there was, I don't remember the dot, I think it was 5.12.11. So they've been doing 5.12 for a while and they did another one just in May this year. One of the things that happened last year in January is that they announced that Qt5.15 wouldn't, it could be LTS, but only for commercial customers, right? Which is like, that's not cool, right? Because, okay, whatever, I mean, you do this, like most of the people doing the Qt development are from the Qt company. So sure, you get to decide that. But one of the reasons they argued, right, was like, yeah, you know, it's like, we need lots of manpower to do these backporting to Qt5.15. So yeah, we're gonna put it behind the commercial customers. So, you know, they pace for itself. And fair enough, I mean, sure, there's lots of work to do, backporting stuff and whatnot. But I mean, they're still releasing 5.12, right? So that argument doesn't work a lot because like, why do you still release 5.12 as an open source product, but not 5.15? That's their decision. There's not much we can do about it, right? They are their own entity, and they will do whatever they think it's better for them. So yeah, the first release, the first commercial release of Qt5.15 was in March this year, one month earlier than the last 5.12. So do we need as KDE long-term support? Personally, I think we don't in the most of the cases, right? Until now, we have not had been using either 5.6 or 5.9 or 5.12 extensively, right? Most of our distribution channels be like either like links distributions or GSD distributions or those kind of big monsters that release our software to get up with a million more things. They always basically been either on the last version, if it's a rolling release kind of thing, or on the Qt version that was released when they did the version, right? So like if you had Fedora 31, so whatever, Fedora 31 had the Qt that was released when Fedora 31, right? I don't know. There were not really many use cases for the LTS, and for things we release ourselves like the app images or the Windows binaries and stuff, we mostly always went to the last Qt2, right? So we didn't really use the long-term support of Qt much, but Qt5.15 is a special case, right? It's the same that happened with Qt4. Qt6 has been released and there's been 6.0 and 6.1 and 6.2 is almost around the corner, and now maybe with Qt6.2 we could start using it, but it's going to be a while until we do, right? If you've been doing the week attending the frameworks talks or buffs, it's not going to happen overnight, right? So we are going to be using Qt5.15 for a while, so we did the best thing we could, given that the Qt company didn't want to keep an open source version of Qt5.15, which is creating our patch collection, right? We don't need a patch collection. It might have just been the distros doing patches, right? This happens relatively often that for unreleased software, distros keep patches on top of the release software, but that's just so terrible, like you go and check the patches that one distro ships against one package and then that hasn't been released maybe for like 10 years and go to another distro and they have different patches and it's like that's not good. So we try to make that boom happen and centralize everything in one place, right? So that's what the patch collection is. So what do you mean by patch collection, right? It's a weird name. Well, it's actually not a patch collection, it's just a git repositories, right? So they are hosted in Invent, which is our GitLab. That thing over there, Invent.qt slash Qt slash Qt has like, I don't know, 20 or more repositories inside, which is all the Qt repositories, right? It's basically a mirror of those repositories. It gets updated every three hours, I think, last time I talked with this admin. And on top of the mirroring, we have our own branch, right? So each of those repositories has a KDE slash 515 branch, which is where we put our things. That branch was created on the latest commit available for the 515 branch, which is good, because so that's past 515-12, right? There are a few more comets there than the, sorry, 515-2. There's a few more comets there than there are in the latest available Tarval. We have to assume those are nice book fixes that the Qt people wanted to have released, so that's why we started from there. Unfortunately, some of the Git repos had changed version already and some haven't. So some of the Git repos started calling themselves 515-3 and some others still didn't. So it's not super awesome if you compile everything from there, but life is tough. So as you can see, it's not really a patch collection. It's just Git comets, right? I mean, Git comets are patches, but yeah, they're actually Git comets, right? So in that KDE 515 branch, well, branch is one for each repository, we have comets that fix at least one of the issues, which is either security issues, right? So like, there's a huge issue with the PNG handler and when you load the PNG, it will delete all your files, right? I mean, that hasn't happened and it probably won't happen, but that would be one of the cases that would happen or crashes, like when I, I don't know, connect to a website that uses SSL, blah, blah, blah, it crashes, so we would fix that. Or, I mean, more generic functional defects, like, I don't know, there's something wrong with Cupid's button. I mean, that's, that's kind of strange because Cupid is very well tested and very well used, so it would be much more of an edge case, right? If that happens, but we just covered our basics, right? So given your description, you could, like the description I just gave, you could say, well, you did the fork, right? We call it a fork. We call it a patch collection, which is like nobody knows what the patch collection is. People know what a fork is, but we don't think it's a fork. We don't have new features, right? So it's only backfixes in the broad term of a backfix, and on top of that, we require every patch that we're merging to our branch to have it being first merged or released or developed or committed in the Cupid then branch, right? The Cupid then branch is where the Cupid 6 development is happening. And that makes a lot of sense because eventually we're going to go to Cupid 6, right? As we mentioned, it's going to be this year or next year or the other, but we will use Cupid 6 at some point. And all the fixes we have for 515, we obviously want them to also be in Cupid 6. So just do that. Let's put them in Cupid 6, and then we just cherry pick them into our branch, and everyone's happy, right? Of course, there's a star there in every, right? So it's every star patch. We already actually have at least one patch that is not upstream, and that's because the file disappeared, right? So that file doesn't exist anymore on Cupid 6. So obviously, there's no reason for that fix to be in Cupid 6. So what? I mean, we're not going to give ourselves some rules that are so, I mean, strong that prevent us from actually fixing what we want, right? So the guideline is if we backport the patch, it has to be a backport, right? So it has to come from Cupid 6. But if there is a really, really, really, really, really good reason for that patch not to be in Cupid 6, like the class doesn't exist anymore, well, then we will accept the patch potentially, right? We have a free software focus in this patch collection, or non fork, as I call it sometimes. If you come to us and say, you know, there's this comment in Cupid 6 that makes it not crash in QNX or integrity, it's like, yeah, congratulations, you can carry this patch yourself, right? It's like, there is no free software in QNX that I know of, or if there is, it's very limited and we don't have access to QNX or whatever. So it's like, yeah, free software focus, right? Which it makes sense. So who decides what goes in and what doesn't go in? So it's created by a small group of people at the moment. I think it's eight people or seven people counting myself. So it's not very big, but it's reasonable, right? So we can each other make sure that we're not making mistakes when cherry picking patches and whatnot. That group of people is the intersection of people that are KD developers and Qt approvers. So it's people that know both worlds, like the free software world and the KD and the Qt world, which is also free software, but more narrow and Qt better. So we thought that was a good starting point, right? Obviously, that doesn't mean that if you're a free software developer that is doing Qt software outside of KDE and you're a Qt approver, or maybe not a Qt approver, but you can prove to us that you know Qt very well and you want to join helping us talk to us. I mean, this is not a very select club, right? It is the club that we tried to make big enough that it would work, but we're happy to have more people involved. Okay, so now you've told me what it is and it sounds like a good idea, right? As a user, I want the fixer, right? That's what users want. I mean, they sometimes also want features, shiny new features that are good for users, but they also want fixes. So how do I get those fixers? Yeah, that's a bit of a hard part right now. We're not making releases, and I know this is not very... This is a bit controversial sometimes, but we decided not to make reasons because we... How do you make a release, right? So the Qt company has released something they called 5.15.3. We could also make a release and call it 5.15.3, but that would be the most confusing thing ever, right? So we should not do that. So we could call it 5.15.2. Random number or .kde.1, that might work, but when do we make the releases? It's like we just get patches into our Git repo as we see the problems being an issue, right? So we see an issue. It's like, oh, this needs fixed, and we put it. So did we do a release every day or every time we do a commit? I don't know. We went for the decision of not making releases. Obviously, as everything can be changed. There was a recent discussion on the release theme about this, but it kind of died a little. So as a user, you can kind of manually compile it from Git. This is terrible. It will take forever once you start compiling Qt web engine. But that's a way. If you're a developer, we switched KDSRs to use it, I think, last week. So you will get it probably. If you're using a flatback app, the flatback grind time is built from the Qt, the non-fork we have of Qt. So every flatback app is fine. I know it's used in some distros. To be honest, I must apologize here, because I didn't do as much research as I should have. I know Arch Linux uses it. I'm almost sure K2 uses it. I saw a patch yesterday for Open Suicide to start using it. I think it said use the KDE patch collection. I don't know. Open Suicide is a bit confusing to me sometimes, because it has lots of releases going on. So I don't know which of the releases it applies, but there is some work going on there. So I think, as a user, you should talk to your distro and ask if they're using it. And as a distro, you should talk to Asip Luzon and explain your pain points. I do acknowledge that the not-release part is a pain point. So let's try to have a better conversation there if it's really blocking you. But I think it's a good idea to people start using it. So if you're a developer, how can you help? We're kind of lucky here in the sense that the development workflow changed recently, and they decided that everything is going to go to the development branch, and then fixes that are actually fixes will be cherry-picked backport to the branch that needs fixing. So if you fix something nowadays in depth, you would mark it with, okay, this is a back, please backport it to 6.2, maybe 6.1 and 5.15, which is great, because then we can just go to the commit log and see everything that has been marked as this needs to be cherry-picked to 5.15. So I wrote like 10 lines of terrible script and brought one of the script that I run every day, every two days that just creates an issue in this URL saying, okay, I found the commit that is marked as this should be the backport to 5.15, maybe we could have a look. One thing we decided to do is to not backport everything blindly. We could have done that, probably not the best of ideas, because the fact that someone made a commit against that and said, yeah, this needs to be ported to 5.15 doesn't mean that A, it will have to reapply one-to-one where it happens often that you need to do small changes because the code has changed from 6.15 and B, I mean, it doesn't mean that it might not break something in 15 and since we don't see everything that goes on on the 5.15 branch, they might have had a commit that just went directly there and we didn't see it. So yeah, we just backport the things that we see that make sense. I mean, we've backported a lot of Wayland things because Wayland is one of the things we're working and it slows the improving, so we've backported lots of those. We've backported also, I mean, one of the things we first really realized we needed this for is GCC 11 was released and it changed a bit the includes for the standard library, like for the C++ standard library, to be better actually. So they include between themselves a bit less, but that means that some of the cute codes stopped compiling, right? Because it's hard to figure out all the includes you need. You basically used compile and if it's compiled, it's like, cool, this is not right. It's that works. But with GCC 11, there was some, I think it was limits include that is not include anymore while including, I don't know, STD vector or whatever. So cute stopped compiling. So we definitely needed that, right? We needed a way to have a cute 515 that would compile with GCC 11. So that was one of the very important things we decided to backport, obviously. So a bit of the future, Katie will move to Qt 6 at some point, right? I mean, as I mentioned, probably not this year, maybe at the end of the year, most probably next year, right? That means that obviously our focus on maintaining a 515 budget will decrease a little, not totally because obviously distributions are going to keep shipping Plasma 5 for a while, right? So we will still maintain to some degree the 515 budget for very important issues, obviously, right? If you imagine that GCC 12 comes out and we have the same problem that thinks of compile, obviously we will fix that, right? But I mean, I think it makes sense that as we move more towards Qt 6, we will put less effort on this budget collection. So 515 3 was released on March, as I mentioned. Will we get these as open source at all? I don't know. I mean, there's this clause about Qt having to release the things 12 months later and then they release them. But I'm not a lawyer. I don't know if that actually applies or since they already released Qt 6, they are already covered by that. We will see and what will happen if they actually release it. If they actually release it, it's going to be kind of a pain for it. I mean, it's going to be good, right? I mean, if we want them to release it, don't get me wrong because it will obviously have fixes and we want those. But if they release it to the terminal, how do we mix that with the big backfixes we already have or not? So I mean, Qt company people, if you're listening, please do release 515 3 as open source and please do release it as a grid repo so we can just rebase, merge, whatever, which will make our life so much easier. So Qt is releasing 6.2 soon-ish. I don't remember, but in a few months, and it's going to be LTS again, only commercially, right? So are we going to have a 6.2 KD patch collection? I don't know. I mean, I don't have a, I can see the future. But as I mentioned before, there hasn't been much use for intra version LTS releases in KD. So my, if you made me bet right now, my bet would be that we wouldn't have, we will not have a 6.2 patch collection. But who knows, right? The future might be interesting in this regard. Okay, so this was the end of my talk. I want you to ask yourself these four questions, and I'm going to have to give you my answers. So in case you were not paying attention, you can get four quick overviews of what it was about. So who's doing this? It's us, it's KD, right? So when are we doing it? We're doing it right now. How? We're doing it in Invent. There's some branches that we cherry pick commits from the Qt company, but not the Qt company, the Qt upstream committers. So we get the fixes we need. Why? Well, because I mean, we need it, right? That we're going to get, we're going to be stacked for the good, for the good definition of stack with Qt 515 for a while. So we need to make sure that Qt 515 stays in good shape, right? That's it. Now, I think I have some time for questions. So if there are questions, I will try to answer them as best as I can. Yes, thank you very much, Albert. We indeed have time for questions, and we do have questions. So starting with one from Jonathan Riddle, will the Qt 5.15.x commercial releases be open source at all, or does the Qt free Qt agreement not require that? Right. So I mentioned that in my Minus one slide. I'm not sure we have to look at that more carefully, because as I mentioned, there's, I mean, there's lots of legalities around it, and it says there has to be continued development of Qt, blah, blah, blah, but that Qt 6 is continued development of Qt, right? So if that applies to all the releases and only some of the releases, I'm not sure. I should know better because I am part of the Qt free foundation now, but yeah, I don't have an answer for that. I mean, okay, but yeah, we have to look into it. Okay, next question also from Jonathan is the Qt ABI has been bumped to 5.15.3. Are there plans for when to bump it again? Right, so that's the thing I mentioned too. We didn't bump the ABI. The ABI was bumped for us, right? We started on the top of the Qt 5.15 branches, and the ABI number had already been changed. It's not us that has decided to change anything. So we are not going to change anything because we didn't change this thing. So it's going to be stayed there forever unless we get releases from Qt and we put ourselves on top and then it will be changed, but we're not going to change that. Okay, thanks. And the final question I see here is from Shinjo, and I'm sending a link that was part of the question in our chat here. Have you heard about this patch set probably originating from Telegram? It seems to be a patch set to Qt. Okay, we have not seen that. Yeah, I just clicked the link. I had not seen that before. I'm not sure I should be looking at this because if those patches are not contributed upstream to Qt, that always creates weird licensing while we're licensing issues. So I've closed the patch now, but yeah, I mean, we should have maybe go talk to them and say, hey, work with us. Because as I mentioned before, it's always a silly idea to do the same thing twice. If you can do it once, why would you do it twice? So it doesn't make any sense for us to be keeping a patch set and for the Telegram people, if this is the Telegram people keeping a patch set, just let's keep one and everyone will be happier. Of course. That was all of the questions. Albert, thank you very much for this talk, for this presentation. And yeah, we'll be seeing each other probably on the closing Yeah, closing sessions. Okay. Thank you, Albert. Yeah, thank you. Bye.