 Well, hello. Welcome to the Jenkins documentation office hours. Today is April 6. This is the EU-US edition. And today we have myself, Mark Waite, and Bruno Verakten. Thanks for joining, as always. Today on the agenda, a couple blog posts that we've published recently. Just a note on the Jenkins Awards, Debux France, just to highlight that that's coming shortly. Google Summer of Code has been making lots of progress. We're going to highlight some of that. Some of the improved process, CI process for Jenkins.io and what that means. Some discussion about how we can resolve the number of open pull requests or at least track them and figure out what to do, what we can do to help that. The Jenkins Weekly and yesterday's LTS release are using new PGP signing keys as well as the Windows MSI installer signing certificate. So a few different updates there we'll talk about. The LTS was released successfully. I just the other day submitted some additional guidelines for the contributing guide for Jenkins.io. Specifically, this was for images. The participation and engagement with Jenkins, just I thought it would be a good topic to talk about for a couple minutes. And then provided we have time, some early end of life for CentOS 7 talk. This has been something we've been discussing for a while. And then the end of life notifications in Jenkins Core, again, that is something that we have been discussing over the last few weeks. And if we have some time to discuss that, we can get there. Is there anything else that should be put on the agenda or any questions or concerns before we get started? All right. Perfect. So first things first, we have two recently published blog posts. One is from Mark about the new Linux repository signing keys. This is something that we have been working on and just got updated. These are in effect as a weekly 2.397 and LTS 2.387.2. So the most recent builds have these integrated in already. Yeah, with sincere apologies to those that we disrupted because we didn't detect this soon enough. It would have been much better if we'd given warning months previously that this was coming and we would have changed on a knife edge. We didn't. We missed it and we left people on the LTS broken for about a week. So unfortunate. Sorry, we'll fix it. We'll be better next time. And we have a whole three years to learn from that mistake. So funny time. And then the other blog post. Oh, and a quick note on this. So this information is also linked in the change log. The upgrade guide is available as well. It contains the same information. So we do have this available in several different points. And this has a little bit more information and background as far as what happened and what we did to change things. The next blog post that I wanted to highlight is one that we published at the end of March from Bruno. And this is actually starting a series of blog posts that are about Android and Jenkins and their relationship. Bruno has started by giving a really nice background about Jenkins and Android development. And some of the intriguing and different ways that he's got about using it, which is really cool and really interesting read. Definitely got me thinking about alternative methods for using Jenkins. It's really cool, really out there. And yeah, it's a series. There's one that we're working on now and there will be more to come. So big thank you to Bruno for the blog post series. Anything else you wanted to share a note on that, Bruno? No, you did fantastic. I wouldn't have done as good as you presenting this article. So thank you. I even want to read it. That's good. Oh, and a fun note. This is an AI generated image that Bruno was able to come up with, had AI come up with. So it's a fun little that looks terrified. Anyway, so moving on to the rest of the agenda. So the Jenkins award voting period has officially ended. It ended on March 28th. Thanks to everyone who participated, voted and nominated this year. We couldn't do it without any of you. And the winners will be announced at CDCon, which is May 8th or 9th in Vancouver, British Columbia, Canada this year. So if you're curious, be sure to register and join us there. Additionally, Debox France is coming up next week. We'll have Jenkins presence there. We'll have Bruno and I think at least one or two other people will be there with Bruno. Oh, beautiful. And then Adrian will be there with Bruno. So we've got the dream team there. Amazing. Thank you very much, Bruno. Appreciate it. You're welcome. It's a gift to me being in Debox, being able to talk with Jenkins users and so on and being with the best of them, you know, Adrian and the RV will host a AMR but without further asking anything about Jenkins. And I hope that we will have interesting questions and will give stickers. Those are always fun. There's always a driving point, so good call. All right. Next up on the agenda, so quick update on Google summer of code. So at this point in time, the proposal submission deadline has passed. We got 55 valid proposals submitted this year, which is incredible comparatively to the last handful of years. This is an outstanding number of proposals and more importantly showcases just how interested people are in joining the project and contributing. This is fantastic. Big thanks to Jean-Marc Messin, who's been the org admin lead for this project and is helming this along with Bruno and Alyssa Tong and Chris Stern without all of the work that they're doing, this would not be possible. And right now we're going to have, it looks like we'll have four projects for Google summer of code and lots of work to do with those. We have a lead mentor for each project, which is fantastic. Everything is just shaping up to look really good this year. It's a little bit of a problem that we have too much interest in the project. You know, it's a good problem to have, but there's a lot of folks out there that want to contribute and be part of it and we're just doing what we can to make sure that that's what happens. And more details come on Google summer of code. We are going to be getting into the initial phase of community building and interaction. So as we approach, we'll be getting more into that as well. The next on the list is the improved CI process for Jenkins.io. So airbay has merged change, which saves time and disk space in the CI jobs. Ultimately, this means 36 gigabytes total of disk space freed up for CI.jackins.io, which is massive. This also means that there is 20 seconds saved for job execution due to the not wasting disk space. So overall 4% of the total job time. Now, I didn't have as much insight. Personally, Mark, is there anything else you wanted to share about this topic? Just be aware that we're no longer wasting that time or that space. Thanks to airbay for detecting it. It's an awkward thing to realize. We've been storing something and spending time storing something that didn't help anybody. Great. Thank you very much. In addition to that, we have a talk, we were talking about reducing the number of open pull requests. Obviously, open pull requests, we want to have closed and merged. People are working hard and want to make sure they're contributing and that their contributions get noticed. So the idea is that we can reduce the open number of pull requests and this will also help with disk space usage on ci.jackins.io and ultimately, just something that needs to happen. We were at roughly 30 or so last year. It's gotten increased. So we need to make sure that we're doing better about reviewing and closing out pull requests, but it takes a village community process. So anyone is more than welcome to join in on that. The idea of participating and contributing in Jenkins is not that you have to make code changes or any kind of grand update to Jenkins or Jenkins.io. Testing code, reviewing code, reviewing pull requests, even if it's not code. These sort of things go a long way with not only participating and contributing, but also making sure that people feel their work is appreciated and that it's engaging with others. Nobody wants to work on something by themselves for their own benefit in this sort of open source community. This is the idea, like open source community is the idea. So we want to encourage people to just find what inspires them, what they find they want to work on, what interests them and work on that and take those small steps to get to the point where you can create code changes or big sweeping UI, UX changes or anything along those lines. So something that we'll be keeping an eye on. As we said before, the Jenkins weekly release starting with 2.397 and the LTS release starting yesterday with 2.387.2 are using the new PGP signing keys. There is a blog post and community comments for these. So great instructions from Mark as we said earlier, a little background and further discussion from the community. This is great. This is directly linked to the discourse site that we have. So all these are direct from users based on their findings and usage of this. So lots of great info there and a great interaction from the community there. I don't know that these two, I don't think these things are relevant in this case. LTS 2.387.2 released yesterday successfully. A user did point out that the change log and upgrade guide had the incorrect date. So we fixed that. Thank you to Mark for fixing that and I forget who the user is but thank you for noticing and letting us know. One of the other signing updates that came through is the Windows MSI installer. This was not available prior to a few days ago but thankfully Linux foundation was able to get everything resolved in terms of any sort of legal complications or any other concerns they have. We now have this signed. It's ready to go. It's installed. So this is now available. What a cliffhanger. Not today, maybe tomorrow. Yes, lawyers are involved. Whoa, that was kind of scary. And then, yes, finally we got the answer. Everything works perfectly and Windows users will be relieved, I guess. Wow, fantastic work. Yeah, and I just thank you to everyone that was involved in getting this updated and fixed and changed over. I know it was a lot of work behind the scenes to get this all taken care of and in such a short time period. So huge. And yeah, and everything's signed so there's no risk or concern for any sort of you know, danger there or unsecureness there. So big, big, big win for Windows users in particular. So fantastic. Anything else on that, Bruno? Or just? No, no, no. I'm just relieved too that people will be able to get their daily fix, the weekly fix of Jenkins updates when running on Windows. That's all. Definitely. Cool. All right. Something that we've been discussing and something that I have finally been able to get some protocols put in for and making a lot of good headway on is additional guidelines to the Jenkins.io contributing guide. So my main focus has been images and then after that documentation and book submissions. So I've actually submitted the image guidelines. So that public request is here. It's not anything groundbreaking. It is not anything that is unexpected. It is very straightforward. Stuff like there's a lot of just documentation for adding updates I made as well. But for images, it's definitely using consistent screen sizes, making sure that the area is focused, making sure that when you go to add an image or add a screenshot that it's providing the right content and context for any surrounding information. So just really simple, straightforward stuff that we can implement or set as a guide to help make sure that things are aligned completely going forward or that our accessibility rating can go up. One of the things that I've been more concerned with in this is making sure that alt text for images is used to its fullest extent. ASCII.com can actually handle full sentence structure for alt text. So for screen readers, for anyone with accessibility needs, that stuff is really important. So that's something that I want to have to affect. And I think that by setting it as a guideline, that's a really simple way to set it up without being invasive. Yeah, that will prove handy for sure. When I first started to interact with the Jenkins community, I started by making a few screenshots, you know, because the UI was changing. And I made a lot of errors because lots of guidelines were just implicit. People knew, but it wasn't written anywhere. So I had a lot of back and forth, no, it's wrong. Why is it wrong? Oh, this way. You forgot that. And the compression and the art. And yeah, now that it's written, newcomers will have it easier to contribute to this Jenkins project documentation. Yeah, fine. Perfect. Thank you. Yeah. And I actually forgot to put the compression aspect of that. Bruno saw that. Thank you very much for the reminder on that. Yeah, screenshots and images are an easy way to get involved and make and suggest a change or contribute something. We have, there's a new contributor right now. I'm sorry, I forget the name, but they've been working on the UI updates that came along with 2.395 where managed Jenkins naming conventions are simplified and whatnot. So they've been just doing that. And that's a fantastic way to get involved and get some low hanging fruit. So, yeah. And you know what, with GSOC coming, there is a project about automating screenshots for the documentation. And that could help if this project is still with us a few months from now, that will help the contributor to have the right behavior when taking screenshots, because everything now is available. You know how you're supposed to take screenshots with that guide. Yeah. And I made sure to include the responsive design mode feature that most browsers have so that we can make sure, A, that the screenshots are all using roughly the same size range, but more importantly, so we can take a high quality screenshot that is going to render properly on either a large desktop or a phone. Because I don't know why, because I have quite a large screen, but most of the images I saw on Jenkins.io were limited to 839 pixels, but I don't know why. It's not a problem, but why? Yeah, I've noticed that as well. I'm going through some of the screenshots and pages, especially, like I said, with the newer contributors adding screenshots and stuff. And it's odd that it's such a small size, but it still is displayed. But with this, we can have some form of consistency. And that makes it so folks with a bigger screen won't be able to take an image that's unfortunately scaled more towards their screen than other people's. I ran into that when I was first starting with Jenkins work. So it's something that, again, it's an implied or understood thing that you don't necessarily know until someone tells you. So let's tell people all these things. Yeah. Yeah. And again, that's I wanted to get the image guidelines in first, because I have seen people working on them. The documentation is already laid out pretty well. And book submissions are a new thing. So this was most important for me now that we've gotten this in there. Once I have seen some conversation and responses happen, I'll be far more inclined to merge it once that's accepted. And then add the other guidelines in there. I've also started a community discourse bed for this. So if anyone does want to have further discussion about this or any other guidelines, there is a place to do so. And I don't think I've had any responses yet. So it's a little lonely in there with me alone. But, you know, I'm waiting. But yeah. So plenty of places to talk about it. The pull request is open. So it can be reviewed, suggested, added, whatever that anyone feels like. So yeah, just keep an eye out for more on that. And then the next thing on the list again, ties back into the idea of just testing, trying out reviewing pull requests that come through. I've heard from several developers that they really appreciate the fact that they see someone else working on something that they're interested in. And it inspires them to also then work on it. It's solidarity, feeling it's a matter of knowing that your work's noticed and appreciated, which is really, really huge and crucial to anyone doing open source work. This is kind of appreciation, gratitude, acknowledgement is something that we want to constantly have for everyone involved. So if you're not feeling confident in your coding skills, like myself, there's ways to review and test documentation updates. There's ways to review simple code changes that are not so involved that it can't be discerned or determined. There are various parts of Jenkins that you can work on, specific plugins. We have the web components for the Jenkins header and footer now. We've got the blog, we've got the story site, we've got so many things that can be influenced that it doesn't have to be one specific contribution. These are all amazing ways and really accessible ways to get involved with Jenkins. As we see the Google Summer of Code participants ramping up, as we start seeing more people becoming involved, this is the kind of interaction we want to support. It can feel very daunting to get started with Jenkins if you're not sure where you want to start or how you want to add. I've seen it several times in the getter channels of people saying, hey, I'm new with Jenkins. I want to get started. Where can I start? And nine times out of 10, I feel that they're one of their first things they say is it's just very overwhelming. There's so much. It's a big, big, big, big project. No one's going to sit here and dispute that by any means. But if we can give folks either a detailed way of how they can figure out what they want to do or point them in places where they can then figure out what they want to do, that's just a huge... When I first came in to the Jenkins community, I just had to look at the repos and found that there were more than 2.5k repos. So I was freaking out. Where should I start? Well, that's quite something. And later on in the process, I was kind of bothered because I had missed a few interesting PR that I should have reviewed or participated in because I hadn't put the notifications on. So I put the notifications on and then I was overwhelmed by the quantity of notification that was... I couldn't do anything with them just pining up. So I don't know what's either the right thing to do with Jenkins repos, but yeah, you have maybe to do some cherry picking every day or something. But for sure, if you're interested in participating in the Jenkins community, you will find something. There was something waiting for you. And I must seal a line from your forthcoming blog post. Jenkins has a way to fill that need. Whatever it is, Jenkins has a way to fill that need for you. It might be a specific plugin that helps you do your job. It might be you feel inspired to make a new logo. The possibilities just run the full gamut of simple to complex. I can't state enough that as a Newark contributor and participant of Jenkins, that it's very overwhelming if you're not really sure where to get started. It can be very daunting and it can be kind of scary to be real. Finding that one thing that can help anchor you to the project or help make sense of a part of the project, even a piece of the project, anything that grips you is more than good enough to work on or participate via. Yeah, it's also very rewarding. I remember at the beginning of my journey with Jenkins, I had a need with on 32 bits Docker images for Jenkins. So I made one and I made my first PR and it didn't work because I didn't know the project enough for it to be an effective PR. The people guided me and this PR got abandoned. We don't have Docker images for Jenkins on 32 now, but it will come in a few months from now. Anyway, but we now have some arm 64 bits because I made another PR and then got accepted. The community globally is pretty welcoming. So if one subject doesn't press you with Jenkins, you should find mentors, people willing to help you and on board you on the Jenkins community. That's something I really love with the Jenkins community. Yeah, I've had the same experience, frankly. My first PR definitely didn't work. I was not sure if I was making things properly, the whole nine yards and the community stepped up. I felt more welcome and engaged with the community than anything else before. And it really does make a difference when you're trying to just start. Having that person to introduce you to Jenkins is amazing. Having people in that you never met and might not ever meet thousands of miles away work with you, help you online, asynchronously, regardless. I mean, that's a really neat experience and something that not everyone can say, frankly. So I think that just makes this a lot more of a special community in terms of the outreach and engagement that we offer for new and returning users. Yes, indeed. I won't be naming names of other open source communities, but I've got some other experience with other open source communities that did not go that well. Yeah, I mean, that can happen with anything for sure. I think we just got something special here with Jenkins and the community that we have. It's very open, very engaging, and everyone's working towards progress and positivity and like a real end goal of making Jenkins great. So nice. On that note, there's a couple, like I said, there was a couple other points here. So just really quickly, early end of life for CentOS 7 is something that Mark has been pushing for. It's approaching anyway. The CentOS 7 is no longer being supported. It's been in maintenance mode since 2020. And there are plenty of alternative options and recommended options that we have like Altma Linux, Rocky Linux, Oracle. Like there are several choices here. We're starting to incorporate those into the documentation. But this is something that we have been discussing and considering for a little bit. And at this point, we just really just need to get a Jenkins enhancement proposal going for it. And then we can track everything, have those conversations there and work on that. So more to come when we get that JEP actually set up. And something else, the end of life notifications to Jenkins Core. Again, this is something that we've been discussing. We want to find a general solution for end of life date for any of the products or platforms that we're using. So the CentOS 7, I think the older Debian versions, like just any older version of stuff that's coming end of life. There's sites like endoflife.date that have an API we can interact with. But ultimately, just we want to find a way to alert users, let users know that this end of life is coming with enough time and cadence to give them the ability to update or find that other solution. We're not going to stop supporting things on the drop of a hat. These are things that need to be taken into consideration and worked through very diligently. So nothing's going to just happen in that sense. But we do want to give that courtesy to users of Jenkins. So again, more to come on that when we have a better idea of what the output will look like. Is there anything else that you want to talk about, Bro? No, thank you, Kevin. And like I said, Mark jumped off earlier since we're doing the 2.387.2 live stream between him and Darren Pope. So that's going to be available on YouTube and it's happening live right now. So yeah, if you want to go check it out, by all means. However, that is the end for our session today. Thank you as always for joining. And the video for this will be available in 24 to 48 hours. Thank you very much. Take care. Thank you, Kevin.