 Here we are. Okay. Good afternoon. Good morning. Good night to everybody around the world. This is March 9th, Google Summer of Code office hour. So welcome everybody. Today I have some general announcements to do and we're going to discuss and explain three projects more in detail. So there will be a presentation and we'll also answer some questions. So the projects will be building Android apps with Jenkins, a Docker-based Jenkins quick start example, and then Jenkins configuration as code, the drift detector. So first of all, we wanted to say with Spring, but with this period around the world, the world makes a big hiccup because of the various time changes in part of the world. So some parts starting with the west coast of the United States or even the whole United States is changing time and moving to summertime. From next week on to adapt to that situation, we're going to start one hour earlier everywhere. So this means that for India and China, as there is no time change there, we'll start one hour earlier, which is good because it's late for you this time. So meeting time will be 15 hours UTC. So 3 p.m. UTC. I didn't make the mass for India and China at that time. So be aware of that. The other thing that I wanted to share remind everybody is that or students or GSO contributors, it's now plenty time to submit your drafts of your proposals. We're getting quite a couple now. I think we're running about six or seven proposals now. They're being reviewed. Continue working on that. It's important. Give some time for the mentors to review the documents. So be patient, but provide them for a review. Next milestone is March 20th. You can start to publish. So register on the Google Summer of Code site and publish your proposals. You will still be able to change and update these proposals until the deadline. But at least you have already one proposal recorded. So you can start whenever you feel ready. The door closed. Definitely April 4th. April 4th is the deadline. Everybody falls dead and nothing moves anymore. No, joking. And it's 4.04. So not found. Yes, indeed. 4.04. So that line is very important for all the students and GSO contributors. Then we will have one month to review and rank all the proposals set up. So we will then start, we mentors will then start our homework. Focus on April 4th is the final date where you can submit your proposals. This set will keep some time aside at the end of this session. It will be a one-hour session, the last one-hour session, because we're presenting now the three last projects, the project ideas. The timing will be about 10 minutes for every project and we'll have about five minutes to answer questions. So there I'll be attentive not to go overboard and that we keep some time at the end for general questions. Are there questions, remarks at this stage of the presentation? I'll leave a blank of a couple of seconds. Then we can start. Yeah, I have a question. Go ahead. Actually, I've submitted my draft proposal and I just wanted to know that in what key points, the other segments are going to rank the proposal. So currently there's no ranking in the review. If I understood your question correctly, this is a review where we help to improve your proposal and it's not only mentors. Mentors, I chase them because I want every mentor to review them the best they can, but there's no judgment at this stage. So we really tell a this is unclear, so this you should rework. Yeah, I'm just asking, like after 4th April, how in what key points mentors are going to rank the proposal? Okay, we're going to explain that later. So currently don't waste too much effort there in a nutshell. We're going to rank the projects or the proposals on the criteria. Is this particular candidate able to achieve successfully the goals of the project? During the summer, will he achieve with the mentors what he promised that he will that he will do without having the mentor having to spend 20 hours a week or 40 hours a week to help or to mentor him. I don't know if this is clear enough for you. The criteria are explained in various documents. I can point you to that. Yeah, thank you, Ma. Okay, so it's basically the likelihood of success. We can come back later to that in the presentation. So we'll start with the first project. We have building Android applications. So we have our Android men with us. Yeah, Android men, why not? The guy who has to build Android apps with various CI CD tools and the latest being Jenkins, of course. So I don't know if you still have somewhere more that description of the project. Of course, I know it, but it's better if I have a support somewhere. So do you plan on sharing your screen or should I do with mine? Can you do it with yours? I'll try to if I ever can find the right link. But you click on the link. I'm going to do it here. Hold on. I can share, but I need the link at least. The link is in the document here. I'm going to, I have it here. I'm going to move because I have my screen set up here. No problem. I have found the link. Yeah, that's okay. I will share my screen. You have it. Otherwise, I'm yeah, thanks a lot, Mark. Sorry for that. I should have prepared that. So let me see if I can. Yeah, I think I got it. Okay, so I can't see you anymore, but I guess people can see my screen. Yes. That's cool. So building Android apps with Jenkins, why not? The thing is, when you search on the Jenkins IO website about Android and Jenkins, you don't find much, if any, and that doesn't mean it's not possible. That means that not that many people have contributed to the documentation or to proof of concept to show that, yes, it's possible to do with Jenkins. So the thing is, when you want to build a mobile app with CI, it's a different kind of CI CD that what you have for other stacks, for example, for the web or for embedded boards or things like that, it's different. You have to have the CI CD mindset, but you also have to have the mobile developer mindset. And the two of them sometimes collide, they don't merge easily. So most of the time, what I've seen in my previous jobs is that mobile developers do their CI more or less by themselves. And it takes them 10 to 20% of the time, and they're not really efficient at that. On the other hand, when people who do only CI try to do mobile CI CD, it's kind of difficult for them because they don't really know the ecosystem, which are tightly constrained by Google and Apple for iOS. So it's difficult to have something efficient. And when I came to Jenkins, I made a proof of concept with Jenkins, which allows to build and release Android apps easily with Jenkins on lots of platforms on Windows, Linux, Vagrant, and on various CPU architectures. So it's something that's worth, but it's only a proof of concept. And maybe it's still too complicated for people to use it in their production. So I was wondering if I could get some help for the Google Summer of Code in order to propose something that would work better, that would target more massive audience, not only people who are familiar with Docker, Compose, various CPU architectures. But yeah, I would like that someone who already has done something with Android development and somebody who is also interested in CI CD and who knows some, not everything, but some of the particulars is the tips and tricks that you need to build and release, to build tests and release an Android application with CI CD. So if you don't know Jenkins yet, that's not really a problem. We still have some time to learn. But I'd like that the people who want to tackle with this project know already about Android because we won't have time to learn Android development before starting with CI CD with Jenkins. So yeah, what I'd like in the end is that we have some documentation on Jenkins.io, not a blog post, real documentation, how to start Android development with Jenkins. And also like that we have a repo somewhere with a working, not proof of concept, something that could work even in production. So that's maybe a little bit ambitious, but that's what I like in the end. We only have 175 hours. Jean-Marc, am I right? Yes, correct. So yes, first of all, documentation so that when people will search for Android Jenkins, boom, they will get some links on Jenkins.io website and links to things, tutorials, how to, whatever that do work for them that they can experiment at home. And then more detailed documentation that will help people to get that into a production Jenkins controller. At least that's a goal. So of course, you will have to study and improve the Jenkins technical architecture. If you don't know it yet, that's not a problem for the time being. But you have to know, you have to have the basics of Android application development because it's very, very specific, at least to me. It's very, very specific. What do you want to make a release on Google Play Store, for example? It's kind of difficult. And if you never, ever have done it, that will take some time to learn. And I'm not so sure that we will have the time to study that. So if you think that you could do that before it starts for real, that's okay. But if you never, ever have touched Android development, maybe you should find another project. I hope I'm not too rude or gross when saying that. But that's the truth. It's kind of, it will take some time, you know, to get accustomed with Android development. So yeah, that thing. And of course, you have to know, even if you don't know Jenkins, you have to know basics of CI principle and practice. And it would be nice if you already knew the basics of Docker, because that's the way I envision it. Or even if we find something else, another way of doing Android build with Jenkins without Docker. The thing is, the proof of concept have made is using Docker. So as this will be our starting point, I'm afraid you will have to know things about Docker and Docker Compose. I think I'll say everything I had to say about that. Jean-Marc? Yeah, thank you. Basically covered everything. Thank you very much, Bruno. Very nice. Are there questions about that project? Okay, fine. Giving some time to people to find a mute button? Yeah, that's smart. Okay. We'll have some spare time at the end. Okay. Is there somebody who wants to present Docker-based Jenkins quick start examples? Otherwise, I will do the presentation of that project. I can help if you want to. Jean-Marc, we can do it together. I'll start. I'll start and you jump in if I strangle too much or get Belly. So I'm going to share my screen. I had time to organize everything. So share. Here we are. And this is the screen. You can see it. Okay. I can see it. Great. I will make it a little bit bigger. There we are. Okay. So I think all of you experienced that very frustrating feeling and say, I've been told that Jenkins is a superduper tool and I want to try it. I want to experiment it and see how it works and then start the difficulties because it's either you have all the machines that you want. You have Linux machines or whatever. There's not a simple way in a couple of minutes to start a Jenkins environment so that you can start playing around with it and having a good feel of its major features and that you have a good demo environment. This is what quick starts, quick starts are for, meaning that you have a setup. You clone a repository. You run three times around the house screaming or you do whatever magic you want and there you have a running environment. Now there are different ways to do it to have this quick starts environment or checklist or whatever. Everybody has the hunch that using Docker compose to have some examples, some automation around it is the way to go. So it should achieve some goals is that it must be easy to run on most environments, not requiring complicated dependencies, run in Windows environment, run on macOS, on Linux, so the various environments, not requiring complicated knowledge, creating SSL keys or these kinds of things. Everything should be in and then properly documented and the updating should be automated in the sense that when somebody wants to try the quick start, he always has the latest version available and running so that we have some kind of CI of the CI environment that we work. So this is a very important project because this is something that's missing and I think that probably everybody here around the table knows that it's frustrating. The first experience is frustrating to get something running but you're proud afterwards when you have done it, but this is unnecessary energy. This is our showcase and we should improve that. Yeah, I can remember the frustration when starting with Jenkins and Docker and yes, of course, I was kind of proud once I got it working, but I didn't know why it worked. More frustration in the official documentation you have installing Jenkins starting with Docker and so on. So you have commands that you can replicate so that it works on your computer, but it's unnecessarily complicated and it makes you do some things, create a Docker file and for no real reasonable reason in fact. So that's kind of disturbing and yes, we have to change that and the idea was to create a set of different Docker Compose files for different needs. For example, the things I just shown with Android for example, that could be an example for Android with a Jenkins controller, an Android agent, a non-Android agent. We could have some examples to build some, I don't know, embedded software. We could have something to build some Java code. We could have something that produces a website and so on and so on and so on. And the magic in that would be that every Docker Compose file would be then tested regularly on ci.jenkin.io so that anybody wanting to start is assured that it will work. It has been tested and every time we change something, we know that it works and that's wonderful. And in the end it's with them. It could also run things to Gitbot so I don't know if everybody is, oh sorry, go ahead. No, no, you're saying the magic word. I was keeping it for the end. Go ahead. But Gitbot is all these kind of environments are very promising and give the necessary standardized environment or infrastructure agnostic environment. So my proposal for that would be to look into Gitbot which has Docker Compose abilities, enough memory, enough CPU and to use that for a demo. Maybe look at other alternatives. I know that the GitHub code spaces has it. It's part of the complete package that you're going to do. And thank you for Bruno for raising it. I was keeping it for the end or I didn't want to throw because one of the problems that needs to be thought about is where Gitbot is currently there is a free tier in it so it's very open source oriented. What happens if they need to make money and say, well, we don't give it for free anymore? So it's part of the discussion. It's part of the things to think about. Very good point, Bruno. You introduced me to Gitbot, I think so. That's okay. The thing is, yes, we may have vendor lock two years from now. We never know. And even same with GitHub code spaces, you never know what could happen two years from now. And GitHub and Jenkins are already intertwined. If ever we would have to leave GitHub, wow, that would be difficult because it helps us immensely every day with GitHub actions, for example. But anyhow, that's not the subject. The thing that we have to remember is that we would like a set of well-working examples for people to be able to start easily with Jenkins and Docker on various platforms, on their laptops with Windows, Mac OS, even on Mac M1 for the most fortunate ones. Why not? Or with Raspberry Pi, for example. That's also possible. That's one of the aims. So not all of them, but lots of the examples should be able to work just about everywhere so that anybody could start with Jenkins easily. That's the goal. Very good. Thank you for the additional color in helping me to promote this project. This is a project that we're both looking for to improve the first impression on Jenkins. Are there questions? I made a good job in explaining it. So are these questions last call go to the next subject? Okay. The last subject, Jenkins configuration is code drift detector. So G-Cask, for those who are unfamiliar with that, is a mechanism where you can describe the configuration of a Jenkins environment as code, meaning you have a text file where you define the various parameters, the various configurations for plugins, for the security. It's rich and it's evolving. This is really a great feature addition to Jenkins. I've been very involved in that in the early days of that. This is great and you can build very sophisticated systems or workflows where the only way to change your configuration is that you change the configuration file, push it as a pull request, merge it, restart it on the production Jenkins, and this is the cycle. And the only way allowed to change the configuration is to do it through the code. And I've seen people pushing that very, very far they even disabled the administrative consoles and did not allow people to go through it. Now this is a little bit extreme because in certain cases you need to be able to experiment or to fix a production incident. You need to change a parameter or you need to change one of the secrets so that you can connect again to a database. And this can be done through the graphical user interface. Oh, but then we start to have a problem there that on one side we have the configuration that's defined as code and then somebody experimented or had to fix the configuration. And if we reapply the jcast configuration, everything will be lost. So you can do it manually starting to compare and trying to know what happened, what changed. And if you're sloppy, there can be a lot of changes. So if you configure it once and then you revisit this configuration, so jcast configuration two months afterwards, there can be have been a lot of things change that you're not even aware because there may be another system element that changes parameters. How do you know? How can you control it? How can you monitor that? And currently it can be done manually so you need to export the configuration and start to compare by hand. It doesn't come in the right order and there are a lot of problems, hurdles, potholes to go that way. But this is a feature that many people told me I say, hey, that would be handy so that I can quickly verify did my configuration diverge, drift from what was charted, what is written in the document. What has changed? Oh, this is the detail I know there was a temporary fix. I can reapply the configuration. So this is the idea about this drift detector. It is writing or creating a tool that you can run that has some command line parameters that will spit out and tell you either your configurations are equal, what's running and what you defined. Oh no, you have this and this and this that's different and the different ways to present it. So you can read in the project proposal there's no additional value for me to read that. I try to explain as clearly as possible what it is, why it's important. The tool can be written whatever you want does not need to be Java because it would work with the command line interface with the available interfaces. There's no limit. The sky is the limit the way you can start going into the internals or you can use existing application interfaces to read. You can do it in Java. You can use a modern language like Golang or even Rust if you want. You just need to have enough people that know that can help you improve your tool and maintain it. So there's no limit there. Are there doubts or questions about this project? Yeah, there is one thing I need to share with you is that seeing the number of proposals, seeing my personal workload, I will not be able to mentor this project. So you're not going to be disappointed by that although I like this feature. I will not be able to commit and we might run into issues finding good mentors for that project. So are there questions or are there doubts about this? Yeah, I have a question please. Go ahead Yusef. I'm already no Jenkins and make a lot of practice with Java and Gol. But what I don't know is Java configuration as a tool. What should I learn to can contribute to this project? The first thing you need to learn is how Jenkins and the configuration as code works and the various APIs. So there's CLI, Jenkins CLI commands that are used to upload, download and manipulate the configurations. So you need to learn those first and then you need from there to think how would I implement that? Don't forget that we would like to see in your proposal some kind of project plan. Are you going to solve that? Does that answer your question Yusef? 100% here. Thank you so much. So I've seen there were questions also on Gitter and so I was not able to answer them correctly. There's some exploration to be done there and there's no simple path or obvious path to solve it. I had some ideas in the time I thought writing that myself. But so first tip, learn Jenkins configuration as code. All the details. Do it, do it. Second, then learn to do it with the command line interface, not with the UI. And once you can reproduce that, start thinking how does the system behave when it's defined as code and when I do it with UI? What can I use to match those or start comparing? Okay. Okay. That's good. Other questions. Opening to broader subjects. If you have questions on the two previous projects, you can raise them now or you have more general questions that you would either want to revisit or ask now. I have a general question, please. Go ahead. Okay. I see you writing in Gitter that if I can provide my abilities in Gitter, I should make at least two pull requests. What should I do in these two pull requests? Just write my name. I'm not sure that I catch the complete context of your question. So I'll try to answer it and you need to correct me if I did not answer it correctly. So what we strongly advise the GSOC contributors or candidates is that they get acquainted with the way the community works, the principle of pull requests and that you do actual work, actual contributions to Jenkins in any form and you can use or you should use these contribution and reference them in your proposal and saying, I know what a pull request is. I know how and this is what needs to be demonstrated that you know how the Jenkins project handles pull requests. What is the review process? What are the communication channels used to discuss them? That you demonstrate also that you have enough understanding of the applications architecture, that you know what are the different components, what's an agent, a controller, that you know all that. This will all help you to demonstrate to us when we do the ranking and say, okay, this particular candidate has good experience. We will not have to spend time to teach him these basic elements. We don't need to teach him how Git works, for instance, or how to do a pull request on GitHub because this is extra cost that we will have to take on ourselves and time that will not be spent on actually doing the project. Is that the answer to the question you had or did I answer another question? Yeah, you answered my question, yeah. Okay, and by experience, by doing two pull requests, you get already enough terrain experience to know what you're talking about. But we're not going to reject or not read your proposal if you didn't do it. But the more you do, the better you're known, the better you're integrated in the community, the better your chances are. Other questions, doubts? So while you think about other questions, so start working on your proposal draft now early. The community will be able to guide you and tell you, oh, this information is missing or we don't understand that part of your reasoning. It's part of the learning process. So open source is all about communicating. And we want to help you to communicate your ideas, who you are, we want to help you to communicate the best available manner. And this is the review process. It's a very bad idea to submit your proposal unreviewed the day before. Because generally, my experience is that piece is missing sections that we don't understand and are not to the point and you've wasted a lot of energy with that. So submit them as early as you can. And it's not a judgment. So remember that. We're not judging your proposal. And old proposals are good. Everybody is good. We just at a certain point need to order them to rank them. I hope this point is clear. Okay. Other questions, other topics you would like to discuss? Other difficulties? Last point, but I think with the discussions online it's obvious. Use the template that's available on the Jenkins GSOC page. Use that. It's a very good guideline of the questions and the topics you need to cover. But please don't forget to fill in your information. Just copying the template won't do it. Good point. Yeah, that's true. That's true. Yeah. I've seen it. GSOC is work. GSOC is a great adventure. And as I explained it earlier in December, I believe it's like climbing a mountain. It's a great adventure. They're wonderful vistas to be seen. But you need to train. And at certain times you're going to tell yourself, why did I start? What in what mess did I get myself? But when you get to the end you will say, hey, that was a great journey. Jean-Marc, we have a question in the chat window from Prince. Can I make proposal for more than one project? Yes. So yes to you and yes to the question. So thank you to have watched the chat for me. Yes, you can submit proposals for as many projects as you want. There's no limit there. Just don't waste our time by submitting a blank project. There must be substance in it like Bruno said. But you can do any. And you're not limited to the Jenkins project. It's not because you're working on Jenkins and we most welcome you on the Jenkins project. You can submit ideas on other projects. So other GSOC organization is the correct word for that. But just remember, listen to an old man. The more you spread your efforts, the weaker the results will be. Yeah, can I add where we want quality over a quantity. So just keep that in mind. That's a very good summary, Alyssa. Thank you. Very good summary. Did I answer the question from Prince? I guess this is the yes. Yes. Okay, yes in the chat. And now open the window. Other question subjects. We had Alyssa. Rahul says, hi, this is my first meeting and first project. Can I contribute Jenkins project? Okay, I see several questions in Raul's question. So with several drawers, and I'll try to answer everything. So first of thing, first here, Raul, welcome. Welcome to have taken the time to join. We have a document that where we keep the notes on all the meeting. I'm going to turn off the screen sharing. It's not useful anymore there. So we have a notes document that we can remind in the, I think that's the one that Chris mentioned in the beginning. In that document are the notes of all the meetings that we held, and there is a link to all the recordings. So I invite you to listen to those recordings. We had also some more general sessions earlier, but they were for that time. So there you'll get a lot of information. Don't forget to join the Gitter channel or the community.Jenkins.io. There you'll see a lot of people read the messages that were before. There's a lot of very useful information available there. The sessions that are referenced, once we started the office hours, we have a presentation in them for every project idea that we have. Listen to it, and there's some very good tips or advices on that. Another question that I see, so first project. So I guess this is the first GSOC organization you're approaching. So I think it's a very good idea to start with Jenkins. We're very friendly and is a very useful product to learn about. There are other organizations available on Google Summer of Code, but I need to be dishonest here and say that Jenkins is the best. So the end of publicity as well. There are several project ideas that are related to Jenkins where you can submit proposals on. And the last thing is you don't have to make it this year. So experience has shown that students that start working early, when I say early, it can be a year in advance, is that start to learn Jenkins, start to learn the product, start to learn the community, start to learn how open source works. And so you can do it by running this year and submitting a proposal. You're most welcome and we will help you. But it's a very good idea that you start getting interested in open source, in Jenkins, submit pull requests, contributions, learn. Hectoberfest is also another event that we're running where we encourage and help newcomers to learn how it goes. And so if you don't make it this year, because Google Summer of Code is very competitive, I need to be honest there. So a lot of people are interested, but we will end up selecting my hunch is no more than six. If we go over six, that would be a miracle. So but it's a handful of candidates. Last year we had four projects running. So it's very competitive. But you can't prepare. You can learn and you can do it for a long period. You can already start preparing for 2024. Now there was a long-winded answer. Raul, did I answer your question or did I completely lose you? Don't hesitate to unmute. And the sir, I know it depends from the country you are. But sir, you add 10 years to mine. It makes me feel very old. So I'm 65. But you're making me 75 with the sir. I know we're here together. So Jean-Marie, Yosef has a question. Would you suggest documentation or something like course to understand how Jenkins works internal as components? Oh, that would be a good idea to start writing that and a good contribution or at least note here. There are documentations available in the now I'm a little bit stuck here. What's happening there? If you go on Jenkins.io and you look at there, Bruno is helping me. I have my I'm sorry, it's not the official documentation, but it's Jenkins contributor side Boston Doost who made a complete series of how to use Jenkins, how does Jenkins work and so on. I think that's a very good way to start with Jenkins. But of course, there also is the official documentation on Jenkins.io. My screen is locked here. I don't have a view anymore. So I try to move this here. If you go in documentation, there's a developer documentation oriented documentation available. Another good tip to start understanding is the series of modernizing a plugin. This will help. And of course, there in pops videos on the cloud beast TV on YouTube. It's a must have he goes very back to the basics for Jenkins and I learned a ton of things with Darren Pope. Yeah, it's true. Raul prerequisites, none. There are no prerequisites, but only if there are many people that submit, we're going to choose the best or the available projects or the available mentors. So this, I don't know if I answered your question, Raul. Yeah, architecture. Yusef, I know it's not available. There's no easy help. The only thing you can do to learn that is take your helmet, take your your rucksack and get into the jungle and start learning starting. This is why we recommend doing pull requests and starting to dig into the core of the code and start learning. There, the usual tips are book at the tests, run the tests with a debugger, step through the code, understand the various components. So these tips are general tips is read the code of other people and grumble on their comments. Because comments are you talking to the people that follow you. So no easy answer for that, Yusef. Sorry about that. This is why in December we told interested people to start learning and get oriented as early as possible. Other questions? Or tell me if I don't answer the questions. So there, I have a question about the length of the Docker based Jenkins Quick Start example project. Now we're we're expecting, now I don't don't have the calculator, my screen here is locked in a weird state. So the project for the Docker based Jenkins Quick Start is 127 hours project. In there there is time for writing to have meetings, there is time to write the documentation, there's time to do the testing. The continuous testing will be very important. I think so we believe that for somebody with medium knowledge of Jenkins and Docker, the allocated time is enough to do something useful and have an efficient result. If you work quicker than that and you can add that in your proposals saying well this could be a stretch goal. If we solve the problems quicker than thought, we could then do this or add that feature or add that feature. So you can describe that. Did I answer your question? Okay, so aim at 127 hours. Describe your project plan. Show that you have thought about it, that you understood the problem and you know what the workload is. So we don't want to see people strolling in the hands and the pockets whistling and saying well okay, I could do something here. No no, we want people that know what it is, that know where to start, how do you say that in English, where you need to grab the stuff and where you need to start working and then you're going to start with that and that important thing also is what are the risks? What could go wrong? If this goes wrong then I'll do that or these kind of things. But we can discuss that in other office hours if you want to come back next week. Don't forget that we're going to start one hour earlier in some parts of the world. We can discuss these strategies and we hear it's open. We can take a virtual cup of coffee together and discuss your doubts or your questions and people are there to help you. Okay, we're reaching the top of the hour. So I didn't think that we would fill an hour but I managed to talk so much with the help of Elise and Bruno, talk that much to fill the complete hours. Don't hesitate to ask your question, lie in it, it's an adventure. Don't be disappointed if you don't make it this year. At least in the process you will learn something useful, you will have fun and there are other additions of this program. But now I'm telling you that you're going to fail. No, you're all going to make it. No, that's the unfair thing. It will be only four or five that will make it. But I don't want to disappoint or make the others lose courage and say, wow, okay. No, it's a great adventure. Even competing is already worthwhile. Okay, I'll stop babbling here. Nice to have met you. A lot of people here are new didn't meet them before. We'll be back in a week. Remember the time. Be careful. We're going to announce it on Gitter to be sure that you don't miss it. And we'll go back to the half hour format, unless there are many, many questions. And normally half an hour is good. And we have that every week. Thank you very much, everybody. Have a nice rest of the day. Good night. Good afternoon. Good day. At least your day is starting. Yep. Okay. Bye bye, everybody. Bye bye.