 Good morning everyone. I want to introduce you, George, with Heptapot Project. Give him a warm welcome. Thank you. So indeed I am here to speak about the Heptapot Project, which is, as you can see, just adding support for Mercule to GitLab. So, maybe first I should remind everyone what GitLab and Mercule are, even though maybe you've heard of them. So, GitLab is a fully integrated forge. That's a place where people can push their code and collaborate. It is heavily based around Git with workflows based on managed requests. It has issue trackers. It has a built-in continuous integration and continuous deployment system. It has many, many other features like a Docker registry, built-in SSO server and client integration with external services. In short, it's a really, really big beast which can be used for almost all aspects of software development. So, I'm not here to prison GitLab to make this clear, but so it's a well-known big system based on Git. Now, speaking of licenses, it is OpenCore. So, it has a community edition which is in self-released under the MIT license, I believe. And recently it's been adopted by some major free software projects like, for instance, Dibion. He was using a customized version of GitLab now and the Nomi project and probably a few big more. And also, it has commercial offers. It is a company with a SaaS system and on-premises offerings. Now, let's speak a bit about Mercure. So, what Mercure is is, well, another distributed version control system. The command line is HG, which is just a symbol for the Mercury element in chemistry. So, compared to Git, it's about, well, the project started right at the same time for the same kind of use cases like kernel development. It is written in Python with some boost from C code and most recently with Rust code to boost it further. If you're interested in that, don't miss Raphael's talk in the Rust Dev Room this afternoon. And being written in Python, it's customizable with a plug-in system that we call extensions. Historically, we had an online provider, think of it as maybe it was the GitHub of Mercure and that was Bitbucket. When they started Bitbucket, they were supporting Mercure only and only later did they had the Git support. Now, the big news today in the Mercure community is that last summer, Bitbucket announced that they would sunset Mercure support. So, you know, sunset, to me, it's like something beautiful, something peaceful, a nice end to a nice day, right? But what's happening now is, well, yesterday, actually, I didn't check, but yesterday it was the last day or maybe the first day where you wouldn't be able to create Mercure repositories on Bitbucket anymore. So, OK. But more worrying, before next June, Bitbucket will remove actually all their Mercure content according to the official communication, the one about synthetic. So, it means that we have to react in a hurry and people who are archiving the history of code like the software heritage have to work really fast so that we don't lose the valuable work that many people have been doing. So, in short, yeah, it was pretty much like that rather than a peaceful sunset. OK. So, now to the main subject of the talk, Helptapod is about bringing Mercure to GitLab. So, technically, this is a fork. This is a friendly fork. We have good relation with the people at GitLab. It's about two years old where it started, of course, as a crazy ID and then a crazy prototype. And if you want to try it, you can download the Docker image or you can try the installation from the sources. And the big news today for us, because it's been lots of work, is that we are announcing free Helptapod hosted service for free and open source software projects. So, this is the partnership between Octobus, that's my company, company I work for, and Clever Cloud, which is a small hosting company specialized in IPS products. And that means that, well, today we can invite any free software project that is using Mercure and especially those that are fleeing Bitbucket. This is a community managed service. To be fair, we didn't write all the rules right now, but we hope to do that in a collaborative way. For now, it's still not so big, but we are growing and we are inviting you, the free software developers, to come to us. Of course, since we are two very small companies, there are some restrictions, there are some priorities because of the urgency of Bitbucket, but come to us and we'll discuss them, and this is all public information anyway. And later on, we'll start a commercial service, too, which should fit all the needs. So, now, the question is, how is that possible? Well, first, Git and Mercure are not so different. From a user perspective, you handle commits, and a commit is identified by the hash, it has an author, it has a commit message, and at the end, you get this kind of graph, technically called DAG, so not so much different. The main difference is how you actually pick the commits you want to display, so it's around the notion of branch, which is really different between Mercure and Git, but for that, we have a mapping, and GitLab is happy, and it's okay, it works. Also, this is not supposed to be readable, don't worry. This is a component diagram of the whole of GitLab, as I said, it's a big beast. And circled in red are the parts that are actually relevant. No surprise, the architecture isn't stupid, so actually it's not so much compared to the whole picture. Now, this is lots of work, and I've invited you for software developers to use the service. Now I'm inviting you to contribute, of course. So if you like return environments, diversity, integration challenge, then you can play with four or five different programming languages, different database storage systems, different protocols, and even built-in configuration manager. So it can be complex, but in my experience, it's rewarding to work to help our fellow developers, because, well, we have natural closeness to that. And last but not least, there are many small issues that can be tackled almost right away, like changing a page which explains how to merge with Git and not with Mercure. That's easy, and you can help people with that. So to finish, I'd like to, just on the line of few points, how is that even relevant anymore to use Mercure in 2020? Well, Mercure is easy to learn, and it's especially important for beginners, the kind that haven't used any version control system in their lives. So typically young students or people that are coming from other areas, like graphic designers, you can do many interesting things with them. As I said in the beginning, it's really flexible, because you have a whole ecosystem of extensions written in Python, which can be used by large organizations to implement specific workflows, or it could be used to simplify things in some cases. Well, it's really quite a world. It also has excellent scalability properties. That's something not so well known, because being written in Python when you start Mercure, at first it feels a bit slower than Git. But if you have one million comets, then often it goes the other way around. It has very powerful query language, which is really useful to me. It's a whole language in its own. And last but not least, it has an innovative, non-destructive and shared history editing capability, which in turn I think can be used to bring more and more automation. I'm thinking of automatic rebasing and cherry picking done the right way, et cetera, et cetera. It's really, really powerful. It's really interesting. So this work has been sponsored by a bunch of really small companies. The biggest one may have 20 employees. And thank you for your attention. And I'm ready for your questions. I hope you have many. Questions? What is the roadmap of Heptavote? I mean, it will be eventually merged into GitLab, Southbase, or it will be a separate project with separate goals and separate lifecycle, I don't know. Do I have to repeat the question? No, you were on the microphone. So we'd like to merge it back with GitLab, of course. For now it's a bit early. We are not in the best position to do that right away, but I hope I could start upstream patches, like for instance, for the Bitbucket import system, which has been obviously more important for us. And later on, I suppose, well, it depends on the success of the platform. If the GitLab people want to take it, we'll do our best to trim it, that's for sure. But it's a bit early, so I'll see you next year, and maybe we can be a bit more concrete about that. Okay, more questions? Okay, thank you very much. Thank you.