 to one. Hello, and welcome to the Jenkins documentation office hours. Today is June 15th, and this is the EU-US session. Today we have myself, Mark White, and Bruno Verrachtin. Welcome. And just as an aside, thanks to everyone who's helped out with any documentation Jenkins-wise since I've been out for the last month. It's much appreciated. Yeah, this makes me feel great about being part of this community. Thanks. Today on the agenda, we have some notes about Google Summer of Code and where it's at. There were some errors in the previous changelog that have been caught. Just an update on the next changelog in LTS, 2.401.2. There was a pull request submitted recently from James Chen that needs a review. Meg has said she's willing to review. I'm back so I can review as well. End of life notifications are now present in Jenkins core, or will be as part of the LTS release next week. Container controller end of life, going alongside of that. Container agents end of life, whether or not the operating systems that are tested should be documented for Jenkins release, which with the new version of documentation could be possible. And the main newsletter has been submitted as a draft, just needs to be reviewed and approved. Anything else that we want to put on the docs office hours agenda today, or does that seem like it covers everything that anyone had on mind? I think I have a blog post to be reviewed too. What is it about? Oh yes, removing outdated plugins when using a Docker container. And I have a PR which is still I guess in draft regarding the use of update CLI in order to keep the documentation up to date regarding the examples. Okay. Do you know what I can actually Yeah, I'll give you the link. Okay, perfect. Yeah, I can just start in here too as well, bro. So no problem there. Thank you. And yeah. Okay. And I get the link for that. Let me just put that in there. Anything else that needs to be added to the agenda? Okay. All right. So then we'll get started here. So first off, Google Summer of Code is in progress. We've seen some work being done on the projects. Thank you to the contributors and participants for the Docker Quick Start project. We're not at a draft pull request yet, but should be there. Just need a little bit more push. So that'll be addressed. The building Jenkins.io with alternative tools has been making good progress. Vandeet has shared a Google doc here that shows previews for what the current and updated version look like. Everything looks really great here. It's really nicely presented. There are questions and concerns about stuff such as accessibility for something like this where the backgrounds changing color may or may not be an issue. That's something that needs to be considered and addressed or just at least discussed. And then various things like the admonitions changing to be more of a highlight than kind of an offset. So some really great stuff here. I think there's a lot of good visual updates for the site itself in the UI. So that looks wonderful. And some of the things that have come up and that we've been that have been getting worked through. So there have been suggestions made as this is being prepped. So big thanks to Gavin Mogan for getting that first implementation of the preview sites put together. There are a couple. Yeah. So the question. So like accessibility for the light blue background navigation is going to be stickied on the left. Is it going to be stickied on the right? Is that something that we should do? Does it how does it work on other you know, in Torah sites? So lots of work still to be done, but lots of progress and lots of great topics are coming up as a result of the progress being made there. Thanks to everyone for their work on the alternative Jenkins.io build options. Really exciting. Mark and or Bruno anything else on Google summer code before we move on to the next topic? Nothing else for me. Okay. No, fine with me. Thank you. Okay. Great. Thank you very much. So for the next topic, Mark, I'm just going to ask you real quickly is I know we talked about these errors that were caught. Have these already been fixed and resolved or is this going to be something or this these changes? Have they been fixed already? They have not been fixed. I was just doing it in parallel while you were going through the meeting now. Okay, perfect. So those will be done. So I was just deleting my debris that I inadvertently left and we're working through it. Okay, great. So that'll be done. The 2.401.2 change log upgrade guide been created. I've added the pull request here in that link and also submitted it to the issue for the release. This change log is different than normal. Thanks to the success of the previous release, we haven't had any issues or anything that really constitutes a proper backboard. So right now 130 people are very happy with everything. So this upcoming change log is going to include the fact that we now have the end of life system notifications available as part of the LTS. So that's going to be a major enhancement that's included in the change log and there is already, Mark's already created a blog post that announced and displays what that looks like and also shares some of the end of life that we are expecting and that are going to be coming up. So I've made sure to include that as one of the references here so that this will be really nice and clear and go a long way in showcasing how much work has been done with that and how that went from a suggestion just a couple of months ago to being implemented now. Which is great. And of course, since the change log and free guide are available for review, feedback, etc., always happy to hear anything. By all means, feel free to take a look. So there was also a new pull request submitted recently. This isn't necessarily new as it has been a few weeks now, but several suggestions to update the UI and just changes to things like font text. Still needs a lot of review and some work done on it. As we said, Meg McRoberts has been reviewing and working on it and providing suggestions. Now that I'm back and available, I will be able to review and provide feedback as well. There looks to be some merge conflicts, so things that will need to be addressed. And yeah, everything looks pretty solid here. It looks like the user, the contributor, is very responsive in working alongside and responding to Meg. So that's a very good sign at least. So Kevin there, the complication on that one is the content that's been provided in a number of cases already exists elsewhere on the site. And so we don't want to duplicate it. Got it. That's one of the challenges of bringing content from the wiki into the wiki that has not been maintained, modified or updated in many years into the currently active Jenkins IO site because there are many times when that material already has a better home somewhere else. And the challenge for this kind of pull request is finding those better homes and putting the content in those better homes. So it's not that Jeffrey's work is not appreciated. It's very much appreciated, but rather it requires a lot more work than probably Jeffrey's ready to do. And so someone who really understands the site and how it's laid out can recommend this piece goes here. This piece should be deleted, etc. This piece should be rephrased. So your review and Meg's review are both very valuable. Great. Thanks for just clarifying that a bit more, Mark. I really appreciate that. I definitely can see where that would be a difficult task for someone to take on if they're not as familiar with one versus the other or just kind of coming from one to the other. There's a lot of places where that information can go, like you said. I've been working in the Jenkins documentation since I started with CloudBees a year ago. And yeah, there's a good chance that there's information somewhere that we can go back and forth and get to. So yeah, I'm more than happy and really excited to take a look at that and see what we can figure out in terms of the content there. All right. So moving on to the next one. And actually, before you just thank you, Bruno, for also reviewing and sharing feedback there. Appreciate it. You're welcome. Something that we've announced previously, but just want to share again, the end of life notifications are available in Jenkins Core. So that was in weekly 2.407. And it will be part of the next LTS, which is 2.401.2. So you can expect to see these sort of notifications appear in your Jenkins instance. And the idea is that it will be a warning within six months of its end of life date. We've also announced some of the different OS end of life that are going to happen for Jenkins and what alternatives and changes you can make ahead of time to make sure that this isn't catching off guard or that you have to even worry about it in the first place. So CENTO 7 is something that we've been discussing increasing or sorry, not increasing, but bringing to end of life sooner than later. So this is our opportunity to say, hey, that we got what we wanted. This side of life notification helps facilitate that and just lets people know where they're at. And this is just fantastic. This is something that, again, we discussed, started talking about a couple of months ago, already implemented and will be able to provide users with even more information in site and frankly control over their Jenkins instance that just makes everything a lot easier. Yeah. Well done, Mark. Kevin, do we have a look sometimes at the Jenkins IO website statistics? Do we know if there has been a peak recently on the blog post of Mark blog post? I don't know, because I don't see any information on community Jenkins IO about, you know, detecting the fact that you're running an outdated OS. So I don't know if people are reading the articles. Oh, crap. To move to something else and everything is crystal clear. So there is no need for any question or I don't know. Yeah. So I've not looked at the statistics for the web page. So I haven't worried about it. I wasn't overly concerned, if only because it hasn't reached LTS yet. And there are a significant portion of the users that are running on LTS. So I expect more noise in two or three weeks. Got it. Thank you. And the tragedy is the sad part is that there are many times when users just ignore our administrative monitors, it's our best attempt to inform them. But if they ignore them, we've made our best effort to tell them. Maybe we should do like the people spreading viruses or something, you know, all your data is belong to us to something like that. You don't upgrade your system. Beware. No, we can't do that, of course. I don't think scary skull and crossbones are going to win anyone over. Probably effective, but yeah, not in the way we want it to probably. Cool. All right. Well, yeah, thank you, Mark, for getting all that kind of sorted and taken care of and mentioned. That's really fantastic. All right. And yeah, alongside that, again, CentOS 7 is already being displayed as approaching end of life. So the monitor should be working and sharing that information. And that means the CentOS 7 end of life is approaching sooner. We've gotten through the discussion and points that we had been talking about last few months and we're where we want to be. The container agents end of life. This is going to be a little bit more involved and will require more work than address the controller. So, some examples of what that might look like or what that's going to entail from stuff like Arch Linux, the versions node monitor plugin and the platform label. Sorry for interrupting, but in the last platform meeting, Damian shared with us Excel sheet of some sort with all the data from Docker Hub. So we can make wise decisions because we have the numbers now. We know what kind of images are totally ignored and what are pretty, which ones are pretty popular. So that's kind of cool. And sorry, I don't have the link with me right now. But it's a public sheet. Well, that's good. That's awesome. Bruno, thank you for sharing. And like, yeah, we can, I can find that and put that link in here after the fact. If it's in the platform sig meeting notes. So, yeah. Mark, anything else on that stuff to mention or bring up? No, more work to be done, but a good beginning and the beginning is valuable enough as it is. Great. Thank you. Something that came up with the versions documentation pages is, should we be documenting the testing, the operating system being used for testing the Jenkins releases? So it's not necessarily as easy to document with the current setup of the documentation in Jenkins.io. However, having the version documentation available and that functionality would allow us to switch documentation depending on the operating system itself. And therefore, testing can reflect that specifically, as opposed to a more general sense of it. And this would just give users the competence in what they're doing is safe and secure and has been vetted by our team. And we can even include further versions like the Java versions. We already have a lot of testing in place, but if that could be even expanded or just put out there and documented clearly for everyone, that much better for the user experience, that much better for upgrading Jenkins, going on to the next release, the next version, the next LTS, whatever it might be if you're a weekly user. So that just gives that much more confidence to the user base. Next. So again, the main newsletter was submitted yesterday, so I'll be revealing that today. And hopefully we can get that published before the end of the week. Bruno has also submitted another blog about removing updated plugins while using Docker, so that also needs another review. And then as Bruno was saying at the beginning, there's a draft PR regarding the use of update CLI. So again, something I'm going to go through and review and provide some feedback on. Yeah, thank you. The thing is we already are using Renovabot, I think. So as Beeneck asked, why would you use Update CLI instead of Renovabot? And the only valid answer I got is that I know just a little bit more about Update CLI than I know about Renovabot. I don't know Renovabot at all, but I'm a newcomer with Update CLI. So that's why any kind of works for what I propose, kind of, because there are still some bugs, which all into the way, for example, Ruby propose, it creates its release on GitHub or the way that Update CLI treats what is perceived as a release on GitHub by Ruby, whatever. So it's not a PR that I hope to be merged quite fast, but it's a discussion, an ongoing discussion, and maybe one day we'll see it merged, but no rush. Thanks for the background, Bruno. I appreciate it. I think it's great. If it's a good discussion, we're having the communities engaging, there's good back and forth, and we're getting things from it. I think it's more than okay to just leave these things open without merging them, have that discussion, make sure that everyone is heard. So yeah, great to know. Thank you very, very much. Okay, that covers everything that I had on the agenda today. Is there anything anyone else that wanted to add, share, make sure we talk about? So could you, in the errors in 2.401.1 change log, open up the hyperlink and let's have you approve it? Not that one, exactly. It's a removal of three, and I confirm that all three of them are mentioned in preceding change logs because we use that pull data value. I could see, oh, this one was already mentioned. If it's already mentioned, it doesn't need to be mentioned. It's not correct to mention it a second time. Right, right. Okay, great. Thanks, Mark. And it's already enabled. So great. Fantastic. Okay, then. So that takes care of everything for today then. I'll go ahead and stop the video recording. Video will be posted in 24, 48 hours. Yeah, thanks everyone again for joining and appreciate it. Thank you. Thanks a lot, Kevin. Bye-bye.