 Thanks everyone for coming. It's early in the morning, 10 o'clock on the, what is it, three or four? For more conference day five almost. So thanks for coming. Yeah, my topic will be continuous integration, build and test for LibreGraphics apps using GitLab and Apple. So for some of you this will not be new. For some of you it will be maybe new. I'll try and be quick with the slides so that we can have a discussion, especially since there are some people from projects in the room who already have experience with that and some other projects that don't use this yet. So it would be great to get this discussion started. So who am I? I used to be a Mac user and I also used commercial graphic software there for many, many years. Until then I finally switched to Linux and one thing I quickly noticed is that installing and getting software, especially of leading edge applications was a bit complicated on Linux. So I started my little project to make this a bit easier called App Image, which is essentially one file applications for Linux. But this talk is not mainly about that. And also what is called a drive-by contributor to open source projects. Usually whenever I see a small thing that's not right, typo or something I like to just go in there and fix that. And also I care a lot about usability of open source applications. So recently I had an interesting conversation with someone from a Libra graphics project, which is really one of the big and old and well-known ones. And I was assuming, well, this project must have hundreds of people working on it all the time. Actually I was a bit surprised when I heard there are not so many people working in the project and also not so many new people coming into the project. And I really started to ask myself, well, why is that? This great piece of software doesn't have more people contributing to it. So maybe it has to do with being welcoming and with continuously building software, making it easy. All these passwords have all skipped the passwords for today. So here's a concrete example. As I mentioned, I like to fix things whenever I encounter small errors. For example, fixing a typo. What I like to do is to go to a website where I already have login credentials, for example GitHub or GitLab. Just go in there, search for the spelling, for the wrong spelling in the full text search because I don't know where that error is, right? Click Edit, fix it, click submit, click send pull request. And now if everything is great, the project will pull it and in three minutes it's done. It's merged, a new build starts, I can download my fixed software and have the error fixed within just under five minutes. Five minutes is really too long. It's a couple of seconds if everything goes right. So unfortunately, the reality can look quite different. Some projects you go to GitHub or GitLab and you notice the project isn't there or maybe it is there but only kind of there because it's just a read-only mirror and you would have to use SVN or Mercurio or some other CLI tool which you first have to install on your machine and then download all of the source code, hundreds of megabytes and then wonder how you send the pull request. The tools actually don't send the pull request because those tools don't have the concept of pull request. Then you go to IRC and ask what should I do now and then you're told, well, just send the patch to the mailing list. You sign up for the mailing list and it still gets banned five years later just for fixing this one typo. And all of the sign up, you confirm the sign up and then you produce a patch and you send it to the mailing list and the format is wrong of the patch then you send it again and do this a couple of times. This is really complicated and that's I think the old way of doing it. So the old world, it really was a bunch of silos where you had download page and the wiki and the forum and the mailing list and some source mirrors and everything disconnected in different systems. Each of the systems needing a different login which I usually forget all the time. So really these silos make it very hard for newcomers especially to a project to just go in, make a small contribution and be done with it. So this is how a typical old world infrastructure could look. A bug tracker where you need to know how to log in. Some websites, CMS, mailing list, SVN, repose, private build servers only some people know how they work, download hosting and then the question are there nightly builds or are there no nightly builds. Then there are mirrors and everything is more or less being done manually copying back and forth things. So really a bunch of silos. Now what I would propose and I'm not affiliated in any way, shape or form of GitLab or GitHub or any of those projects or companies but this is fantastic for a new contributor to open source projects. You can go to one of those websites and just submit your change and everything is nicely integrated. Everything happens in the open. Everyone see how things work. For example doing continuous builds you can just make your change and then look at the build pipelines here's an example on the right hand side where you can see that your build is now running and everything is done correctly. You get the green check mark and you see first your change is now breaking the build and also everything goes right. You can download a file for example a Windows X or Mac DMG or for Linux app image which is one file that you can download and just run. For app images there is also one additional benefit I call it binary diff or delta update especially for those of you testing continuous builds it's very convenient because there you have to download only the few bytes that have actually changed from builds to build and you don't have to redownload the whole application over time. Inkscape a great example. Inkscape just recently introduced all of that and yeah it's really I like it very much because you can clone things you can edit things online without having to download all of the source code first you can get instant reviews of what you have done, what you have broken you can download builds all along the way you can also have a discussion when you have sent a merge request which is the new kind of patch then a discussion starts where people can reference to your code you can do changes it feels very interactive and in the end it gets merged and everyone is happy. So here is an example how this works in practice a person has made their first contribution it's even mentioned there on the top of the screen and at the bottom you see the pipeline has been run and there is a green check mark so everything is fine it's working great. So I would encourage everyone of you who is not doing this yet to just do it and this is basically what I wanted to say so if you came for a lot of technical details this is not the presentation where you will learn about this and I really encourage you to investigate a bit what projects are doing for example the Inkscape project and with that I would like to open the discussion. Yes please. My answer is no way. The only way a project should lose the knowledge of their infrastructure if you put your infrastructure on a modelist or a jubilist like KitLab or GitHub in a way so much knowledge and in order to come back a type of fix is worth that. I want to keep ownership of my infrastructure. Which is completely possible. I will repeat the statement for the video so you're saying essentially a knowledge might be lost when open source projects migrate to infrastructures like KitLab. Yes. So as you might know, KitLab itself is an open source software. There is also a hosted instance where you can have everything operated by others for you but you can also set up your own instance. Sure, we do that. We create our own KitLab instance but then you have got an account there already you will need to make a new account which apparently is a huge problem. I can't believe that I commented on this. I got first-hand experience. I am with Git and Git is hosted and was always hosted in the Chrome Git repository. So it was using some Git I do not even remember because I was not involved. And recently GNOME moved to GitHub on a self-hosted instance. If anyone knows GNOME and the people for the journals they made this huge decision-making process. So, yeah. Basically, for us, we did not lose anything we didn't already have or had not. Can you go to the microphone for a song? Do you recording it? Should I open? Can you talk there? Is there a microphone there? There's one here. I would like to propose if people want to make a question they come and line up over here and then they can ask the question what are you without blocking the camera? So, when I start again. I am Michael Schumacher, also known as Schumammel with a GIMP project. And, yeah, as I just said, GIMP is hosted by GNOME and GNOME switched to GitLab. So, A, you can have your own infrastructure like if you were running some Git server before you can now run a Git server and some web interface for it as well. But it's an important distinction to make that Git is not GitHub or rather GitHub is not Git. Some people already confuse that thing. And GitLab is not GitHub and GitLab is also not Git and GitLab.com is also not GitLab. Yeah. So, about the move itself we lost a bit in comparison to when we moved from Buxilla to GitLab because some of us were really, really, really, really, really, really, really, really used to a Buxilla like stored on a bug list or whatever. One downside of GitLab I want to mention is they have a community edition and an enterprise version. And it can be really frustrating if something you have used in, for example, Buxilla however crappy the software might be and it's really not good is only available in the enterprise edition you install the community edition, hunt for it search for, like, you find it in the docs and then somebody body points out, oh no, this is enterprise. This can be a bit frustrating so if you decide to make a move to GitLab check out what exactly you are getting what you are not getting decide if you want, if the community edition is enough for a self-hosted thing or if you have to really invest into enterprise edition but then, yeah, it's not like you're not going to lose any knowledge that's not the point, that's not the point the point is I wasn't saying GitLab sucks let's not use GitLab Krita is hosted on GitLab on our own instance of GitLab we went through all of this, I know this I know the difference the argument he was making is we should not have silos we should have a single sign on just one place where people go to or two places, but not more I don't want to do my drive-by patches and if everyone moves to GitLab and GitLab own enterprise hosting service then we will lose knowledge because we won't own our own infrastructure for Krita which is part of KD which is also moving to GitLab which we are hosting ourselves we've got our own CI for now we're still keeping Buxilla but that means we keep the knowledge if we would host Krita on GitLab.com or GitHub like Inkscape is doing then we would lose that knowledge and if we wanted to go back because those companies are becoming evil like Microsoft then we wouldn't know how to do it there are at least three points here number one is the silos with silos I don't necessarily mean that everything should be on one central instance like GitHub or GitLab.com what I mean with silos is that when you have inside one open source project different pieces of infrastructure that are not working together you have to log in within that project into a two different systems for reporting a bug getting a build triggered and so forth so my point is that first of all within one project there should be a single sign on then number two ideally this single sign on would accept GitHub and or GitLab accounts which also works by the way when you're doing self hosting by just using the SSH for the single sign up for the accounts doesn't mean and this is point number three doesn't mean that you have to use the hosted instance you still can self host everything if you like I just wanted to answer what the decision we made for the Inkscape project to go to GitLab.com basically we are sort of on our own we were on launchpad before so we did not self host per se we are not in the GNOME repository we are not in KDE so we are not in a big group with a lot of infrastructure so we actually talked a lot on the mailing list about this possibility of going to GitHub GitLab.com or self host either GitLab or something else and we found that GitHub is not free so it was a big bad point the only good point for GitHub was actually that quote everybody is there but we made the decision to GitLab as a trade off basically because we can go to GitLab and then get off that was the main point for GitLab.com and we did not have any infrastructure work before because we were on launchpad which was not very developed at that point by Canonical not really abundant but not really growing or having new things so we felt that GitLab was growing projects with lots more functionalities and since we did not want we don't have a lot of contributors or a bigger group like KDE or GNOME so we did not want to add this work of hosting and maintaining or Git hosting mechanisms so we felt like we can get on GitLab and if they become evil if they become source forge we can get off and self-host if needed but we can have these free runners they have a lot of things that are very practical but we could do if we wanted to so I agree that we are not in control of our infrastructure but we could be if we want and that was something very important Quick follow-up question to you did you already notice some change in the type of contributions you get? I think it's simplified contributions so we got a lot of more contributions than when we were on Bazaar and Launchpad which I was not convinced of that before the switch but it actually happened Thank you I want to just say that our silos are going to change also thanks to work done by Simon so there is one silo which we need to GitLab as soon as possible as soon as possible Thank you That's the perfect ending point for this session Thank you very much