 All right welcome to Jenkins documentation office hours today is March 9th and this is the EU US edition. With me today we have Mark White, White and Bruno Rockton. Thank you for joining us always, I appreciate it. Today on the agenda we have some action items. There's a couple pull requests to review but nothing too urgent. We have a few blog posts that have been published one by Bruno about the mini Jenkins controller that he made. There's the Atlassian sponsorship blog post that Mark has written and we have the Jenkins awards. The voting period is now open and the Jenkins February newsletter which is now published on the blog. I just need to update the link here. This will have a short talk about moving the docs office hours time to potentially earlier in the day. Just a quick note on the LTS release this week. Weekly change log will be reviewed. Documentation transition from Java 11 to Java 17 with Debian 12. This is something we've been talking about for a handful of sessions now. Improving the end of life notifications. This is something that we've discussed in the last two meetings or so and we'll revisit again today. For the CentOS 7 end of life, this is something again that we've been discussing for the last handful of weeks and we'll just touch base on that. If we have time or if there are any other questions we can also go into a quick 10 minute intro to Jenkins. I think this was a remnant from the Asia docs office hours meeting previously. I'll remove it for now but if we want to take a look we can put it back on there. Is there anything else that I've missed or anything else you want to make sure is on the agenda today? Nope. Okay. All right. So there have been a couple of plug, just from new contributors adding a lot of content. It's somewhat challenging and it's a lot and they've done a lot of work to push this through and submit it. I'm doing my best to get through them and verify but I'm still learning a lot about Jenkins so sometimes I need a little assistance and help but that's why we have a full team and that's why we're all working on this together. The first blog post that I wanted to highlight is again Bruno's blog post that he contributed about the mini Jenkins instance that he created. This is really cool. This is something that he brought to Boston as well so it was able to show it off through the attendees which is really neat. Bruno, do you want to speak to it for a second or give us a little insight here? Yeah, I'll try to be quick because won't get me started on this contraption. It's just a Jenkins instance. By instance, I don't mean a cluster. It's just three agents and a controller. All of them being screwed to strand things which is pretty printed and one of the agents is an ARM32 bit. Another one is an ARM64 bit and the last one is a RISC5. That was just an experiment because RISC5 is not a platform which is officially supported by Jenkins and even not by Temurine which we use. So all of this is very experimental but I had tons of fun designing the 3D thingy and installed linux on the various boards and used some Pine64 power supply and had tons of fun talking about that at the first time Jenkins boost. So all of that, I had way too much fun with this project and it's not finished yet. I still have to add some displays and lots of things. So I also have a YouTube channel where I do regular live streams on this thing and I write some blog posts from time to time and so on. Anyway, it's not finished. It's still in the making and to work in progress but I'll learn some things about Jenkins, Temurine, RISC5, a lot of things. So that's the beauty of it. I'm growing with that small project. This is really cool Bruno. Thank you so much, I appreciate it. And I just love the fact that we're pulling back the curtain a little bit to share your kind of like what's going on here in the background and your thoughts on it. It's really awesome and I think is incredibly valuable even if it's still a work in progress. There's so much to learn like you said. Well, thank you so much for your feedback and I have another article in the writing regarding Minigen once again and RISC5. A little bit more information about my progress. And thanks a lot for the shootout. Of course. And I'm hoping that we can have that other Minigen blog post published on the site by tomorrow end of day. We do have scale this weekend. That's not something that's on the agenda but I do want to call out. Scale 2023 is this weekend. Mark, Wade and Alyssa Tong are going to be attending and be representing Jenkins and just really excited and looking forward to the next couple of days with that. And the idea is we'll have that other Minigen blog post up so that it's available during scale. Thanks a lot for your work. Thank you. So moving on the next blog post is a small blog post that Mark had written just thanking and sharing a gratitude to Atlassian for sponsoring continuing to sponsor Jenkins and provide a JIRA so that we can continue to track issues and progress Jenkins development. So you need to scroll down a little bit. The even more important thing is the upgrade schedule. Yes. There will be a little bit of downtime while the Linux foundation installs the new thing. There are upgrades. It's a license upgrade if I understand correctly. And so we don't expect it to take a lot of time but they have to do some work and the work may have some downtime. Good to know. Thank you very much, Mark. And it looks like it'll be later on the day for most folks and towards the end of the day. Bruno, you should not be working on Jenkins issues at that time because that's 1 a.m. your time Saturday morning. I will be sleeping, hopefully. Good choice. Great. All right. Thank you very much, Mark. Appreciate that. And again, thank you to Atlassian for providing and sponsoring Jenkins with all of the resources that you do. This is great and makes our work very possible. Next item on the list, the Jenkins contributor awards voting is officially open now as of just yesterday, Wednesday, March 8th. Voting is going to be available and open until March 28th. So the end of this month. And we have our list of awards and candidates to choose from. All of these people are more than worthy of these sort of awards and even further. So this is a great opportunity to share our thanks and gratitude and appreciation for them. It's going to take place via a Google form that is linked here in the blog post. This is only for the Jenkins awards. The other projects and the CD Foundation themselves have a separate form for their awards and their voting process. You can get that information from the CD Foundation site and repository where their issues are being hosted. Tecton are hosting their own issues and then everything else will be falling under the continuous delivery foundation if I'm not mistaken. So they are the foremost authority on any kind of information or insight you need. But for Jenkins, we have all of these host in our repository and the Google form. So nominations closed last Friday. Again, voting opened yesterday and will close on the 28th. And then the winners will be announced at CDCon this year in May. So that will be a really nice time to just look back at everything and then look towards the future by sharing our gratitude and appreciation and thanks to these people. And the realm of security contributions, advocating for Jenkins, these are all hugely important and we appreciate and want to just highlight all the work that's done here. And then the last item here in the list is the February newsletter. So again, this did just go live not too long ago. Quick thanks again to Roxanne from the CD Foundation for creating these header images. Really nice and make the newsletter pop a lot more. And yeah, we have some highlights from FOSDOM 2023 if you haven't seen the blog post, some update on Google Summer of Code and Jenkins mentoring in our participation. Look at all the lovely mentors and participants. Great. Our Jenkins awards, again, they're open to vote. Lots of infrastructure updates for the platform and some highlights of the different blog posts that we had last month as well. Some governance info and a bunch of information about platform updates and image container image updates. So thank you to Bruno for all of that. More UI UX security and thanks to Kevin for contributing the security update this time around. Really appreciate that. I'm going to need to fix that, but that's okay. But me and the February newsletter is live now. You can go check it out and see all the wonderful highlights from the past month from Jenkins. Next up on the agenda, something that Mark and I have just been discussing. But with daylight savings time in the U.S. being a thing, we were thinking about potentially moving the Doc's office hours to an earlier timeframe, mainly so that we can accommodate everyone appropriately if this is held later on in the day for me. That's going to be, I don't feel comfortable with that. That's too late for anyone in the EU such as Bruno that might want to attend. And I think it's fair. Sorry, because of the light savings time and so on. So you say that you think of making it earlier, but will it be really earlier for me once you have changed time because of daylight savings? And two weeks from now, will it be still earlier or later? Oh, that's a mess. So that's why the Jenkins project states all its meeting times in UTC. So really earlier. Because they are unaffected by governmental manipulation of time. Yeah. Okay, I'll have a look at my calendar and see if it's earlier or later for me. And it will change for me two weeks from now. Yeah, the open question is we could go one hour earlier than the current meeting time. We could go two hours earlier than the current meeting time. This meeting time should serve us, those of us who attend. There's no shame in us saying we want to meet an hour earlier, two hours earlier, three hours earlier. Those are all times that work for the people who participate. No shame in us saying whatever works for us. Yeah. So it's still US and EU. But the reality is we don't have any California-based or any West Coast-based, California, Oregon, or Washington-based contributors. We also don't have any contributors from Alaska, which is even further West, or from Hawaii, which is really further West. And so I think it's perfectly fine for us to say let's pick a time that works for us. Fine. Thank you. Yeah. And the idea, like Mark said, is more just to move from meeting a little bit earlier in general. It's not specifically because daylight saving time. It's just something I noticed in my calendar thought maybe we could just avoid all this. But yeah, we'll figure it out. It's an open-ended question. Nothing's guaranteed right now, so no worries. Yeah. Okay. Next on the agenda. So this week, yesterday, we had LTS version 2.387.1 release. This was released successfully. Big thank you and appreciation to everyone that worked on this. This has been a lot of work over the last handful of months and a lot of updates and changes made it into this LTS baseline. And we also had 2.375.4 release yesterday, as well as weekly 2.394. And thank you to the security team because they took the lead on these change logs and getting these releases out since they did have security updates to push through. Just super, super thanks for their work and help on all of these and getting these things put together. There were tons of UI updates, notification updates. We moved the transition from Antler 2 to Antler 4, which is a lot of work and a lot of just a lot of future thought going into this. So huge amounts of work. I can't stress that enough. And yeah, there's plenty more. You can check out the change log on the Jenkins site. And an upgrade guide as well. There's lots of stuff to go through. We also have the next weekly coming up. So 2.395. The change log will be reviewed tomorrow and Monday prior to its release next week. So that will be great. That one's a bigger release because it's two weeks worth of changes. 2.394 was only 2.393 plus security fixes. 2.395 will therefore be two weeks of weekly changes collected together. Got it. Good job. Thanks very much, Mark. So that'll be a little bit more work than before, but I'm pretty sure I can handle that. Next on the list, the documentation transition from Java 11 to Java 17 with the release of Debian 12. So Debian 12, aka Bookworm, is set to release in April or May 2023. At that point in time, we are going to transition the install docs for Jenkins from Java 11 to Java 17. Java 11 is going to continue to be supported. That's not going to be dropped until next year at the very earliest. So there is no stress or any reason to worry here. We just want to encourage people to use Java 17 as their own baseline. It provides full functionality. It's fully supported now. And just the end of life is going to happen for Java 11. So the sooner we move towards Java 17, the less concern people will have to have when it does come to that time. Mark, go ahead. I was going to venture a proposal for a possible change of idea. We framed it as Debian 12. And Debian 12 was the catalyst. But realistically, I think for the Jenkins project, doing it in April or May, whether or not Debian 12 releases makes sense because we want to make this transition. Debian 12 was the catalyst. I won't dispute that. But I think maybe it's time for us to say, hey, we're just going to set a date for the transition. We're going to do the transition because we know this transition is needed. Any objections from you, Kevin? You're the docs officer. So this is me sort of weighing in. No, not at all. I have no objection to that whatsoever. I mean, the way we've been talking about it, Debian 12 is kind of, like you said, whether or not that's part of it is not as big a factor. More importantly, moving to Java 17, transitioning the documentation to use it. I think all of those things are more than enough reason to just go ahead and transition in regardless. Cool. Okay. That's one. Yeah, I'm on board. And Bruno, you're okay with the same concept? Yeah, of course. It was, I need time to find the mute button. But yes, of course, it does make sense. Of course, I have not seen anybody complaining about Jenkins to know work with Chidike 17. So it does work. It does work for infra. It works for CR. It was just about everywhere. So yes, let's go and move to Chidike 17 in the documentation. Great. Perfect. And just something that we had discussed before. I didn't email Tim to let him know he's aware of the transition and totally on board with it. So we have the release officer okaying everything. We are more than good to go at this point. So it'll just be a matter of actually performing the transition. Next up on the agenda. So this is another, again, another topic we've been discussing improving the end of life notifications. This has been a topic because we've been discussing the end of life for various products and platforms Ubuntu 18.04 specifically reaches end of life next month. So we are looking at various ways to not only make this transition easier but alert everyone to the transition itself and or the end of life deprecation, whatever you want to call it at that point. So things like a blog post, things like making sure we tweet about it, providing announcements ahead of time, notifications in Jenkins or on Jenkins.io. There's a lot of places that we can actually make this happen. It's just a matter of figuring out the best way to go about it. We do have end of life.date as a resource that contains all the end of life dates or end of life dates for a lot of products, if not most of them that we use and work with. So great little resource there. It's got an API that can be connected into systems so we can get some kind of automation going on there potentially in the future. But the bottom line is making sure that people are aware of the end of life is coming and in a way that's not alarming. This is something that needs to be addressed and taken care of by each user in their own system but we should do our best to make that information available as well. We have been discussing a Jenkins enhancement proposal to track all of this. So discussing various deprecations in end of life such as the Blue Ocean container image, the Cento-7 container image, which we've been discussing independently of this, and the Arch Linux aging container. These are all a little bit older and are going to be hitting end of life sooner than later. So the idea is we'll have this proposal. We can track all of that and as we move through we can note down all the changes being made. Is there anything else on that Mark or Bruno that you'd like to add? I know this has been a conversation we've been having in various places. Yeah I think the next step is the Jenkins enhancement proposal and it needs to, I think the challenge will be expressing in a way that it identify the use cases and actually address those use cases with the proposal because the container images are quite different in terms of how we would solve them than an operating system deprecation, right? A container image, we could see a file on the file system. The operating system we really have to ask questions from inside Jenkins Core which operating system are we on? And that may cause more concern or more bristling from people saying hey, why are we embedding that kind of knowledge into Jenkins Core? And the answer is so that we can tell them that their operating system that they're running on is end of life to the Jenkins project. Great and yeah and I can imagine that there's a big difference between the container images and what they rely on their dependencies, all the stuff that kind of make them up are going to, it's all going to be very different. So I can see it being a case-by-case situation. Well and this, the agent container image is yet another condition where we don't, the code, the controller code doesn't naturally run on the agent. We have to do a remote call to execute something on the agent and so finding out, detecting that a deprecated agent is running is, may not be a Jenkins Core topic, that may be a version node monitor topic and that's okay too. Got it, okay thank you very much Mark. And the last thing on the agenda and this is going off the previous points but we have been discussing prep pairing for the CentOS 7 end of life. Mark has been proposing this and explaining why this should happen sooner than later for a little bit now. Everything makes sense. It's relying on ancient versions of things that we don't use. It's been in maintenance mode since 2020 and the end of life is going to be happening next June. It's already not supported by various functions and pieces and so it's time and the idea that Mark is proposing is that we submit a JEP to actually just accelerate this end of life and get this to the point where we can say it's deprecated sooner than later. So the JEP still has to be created but it makes all the sense in the world based on what Mark shared and these are very old versions so yeah it's time to move on. CentOS 8 is fully there and up and running if I'm not mistaken as well so no reason to not move forward. Yeah CentOS 8 or CentOS 8, no it doesn't exist any longer but there are plenty of Red Hat 8 based systems that are available if you want to go to something that's slightly more modern. There's also Red Hat 9 that is now available that is significantly more modern and both of them are a better choice than CentOS 7 for sure. Yeah what I heard with a recent version of CentOS and Red Hat is that there was a change of philosophy let me say. Yes you know downstream versus upstream and that could be a problem for users. Correct and so CentOS may not be the place that they choose to go. They would probably choose Rocky or Alma or Oracle or Red Hat or Amazon Linux 2023 or all sorts of other alternatives yeah. Right and some of those things have been put in the documentation as of this moment but a lot more work needs to be done to make sure that it's across the board. That'll be something I work on with Mark's guidance and we get taken care of as well. So that covers everything I had on the agenda. Does anyone have anything else they'd like to share put on the agenda ask where mentioned. All right then. Thank you as always for attending and joining here appreciate it. The video recording will be available in 24 to 48 hours and yeah take care have a great rest of your day and thanks as always. Thanks and Mark safe travels. Thank you. Yes enjoy scale Mark that'll be a fun time. All right.