 Hello and welcome to the Jenkins documentation office hours. Today is November 9th and this is the EU US edition. Thanks for joining us today. Right now, we have myself, Mark, wait and burn over often. If others come, we'll join and welcome. Thanks to the daily savings time change over for both Europe and US this is a little earlier than it has been lately so if anyone's late no worries. So for the agenda today, the Jenkins two plus two plus two Java support plan blog post that Basel wrote so just highlighting that. We'll touch on the Google summer of code 2024 prep. The contributor spotlight project that we've been working on and we'll find we'll shed some light on that. The October newsletter has been merged but it's not displaying on blog yet just yet. Next week we'll have the next LTS baseline 2.426.1 will be released. October 2020, October fest 2023 has come to an end. And lastly, on the agenda, I have some time and designation just talk about the update CLI. One of the pull request was merged just the other day and then there is another idea that we've been discussing that we can talk about as well. And it's going to go on the agenda for today or does that cover topics for one. Great. Well covered for me. Thank you very much. So, starting off so the Jenkins two plus two plus two plus two support plan. So this is something we've been discussing for a little while now. This is a blog post. Thanks again to him. But this goes through and explains the idea concept potential proposals that we had just discussed and the accepted proposal that we're going with. Again, this is all been discussed prior but essentially the idea is that we want to enable and empower both enterprise and developer. So really large scale and really small scale, we want to make sure that developers can develop and adapt quickly, fastly and get the latest tools. But we also don't want to disrupt an enterprise set of users with changes that they may not be ready for or even able to make at that point in time. So, we've come up with an idea that we think will please everyone granted you can't please everyone but for the most part this does address a lot of the concerns that have been shared thus far. And gives a very clear explanation ideas to what Jenkins will be able to support in the future. The idea is that we'll have the supported version for two years will introduce the next version when that first version becomes required. So then we'll have the next version supporting for two years where the first version is required. And in the last two years of the first version life will require the second version and introduce the third version as we start to support that. So, a little, I could have described that a little bit more clearly, but Basil's got great images in the blog posts that do a really lovely job of explaining what I just said. It's also got some key dates some ideas of what to look out for and just really generally a nice presentation of what we've been discussing throughout the community in the Jenkins advancement proposal that has been submitted. That link is here. There is an ongoing discussion about concerns issues anything that anyone might have regarding this, please, by all means chime in here. Add your thoughts. This is something that's really important we want to have as much consideration as we can going into it. Again, this is not a complete solution for everyone, but we've come to a decision that really does work for the majority of folks. I'm really happy about all that and all the community participation. Next up so Google Summer of Code 2024 is in preparation mode. Chris Stern has stepped up and is going to be leading the GSOC project next year. Really amazing. Thanks to Chris for taking on that role. The initial documentation to organize the event itself is being generated and submitted now. I know Chris has submitted some updates for the documentation on Jenkins.io so that is actively being worked on. They're collecting ideas, recruiting mentors, normal GSOC prep and if we have any documentation ideas for next year, they're willing to consider that as well. Of course, not doing this alone, this is done with the help of the additional organization. Bruno, thank you. Alyssa Tong and Jean-Marc Missin. As always, thanks to everyone for their work and dedication to Google Summer of Code. Next up on the agenda, this is something that I've mentioned previously. I don't think we've gone too in-depth on, but this is something that we've been working on is the contributor spotlight. The idea is that we want to acknowledge the really hard work that goes into keeping Jenkins afloat and working and operating the way it does. The contributors that are heavily involved in Jenkins' well-being and health. We want to really give them a chance to shine and highlight and appreciate what they're doing and what they've been doing for quite some time now. With the help of the advocacy and outreach organization and a lot of the other SIG leaders, what we've been doing is determining who the top contributors are or the heavier contributors to Jenkins are and then reaching out to them with a questionnaire to understand who they are as people, understand what their backgrounds are, why they chose Jenkins, why Jenkins has helped them, how has Jenkins helped them. The idea is we want to showcase and highlight all the hard work that goes into Jenkins and the people that are making it work. So what we are going to be doing is we're going to have a new contributor spotlight site that Chris Stern has been working on and a big thanks to Chris for all of his help with generating the site. Thanks to Christina Pizzagalli for providing the mock-up of the site and again all the contributors that have helped with this. So we're going to be publishing this and getting this live once it's ready. We're working with the infrastructure team right now to get that new repository integrated into the infrastructure. And what's going to happen is we'll have a new contributor spotlight every week or two. There's going to be a regular cadence that these are going to be published and we'll be able to highlight these people, these contributors, and actually let them tell you who they are and why they love Jenkins, why they contribute to Jenkins and what Jenkins has done for them over the years. And it's really great because we get contributors from all different walks of life, all different backgrounds and all different experiences. So just seeing some of the similarities and some of the differences is really nice and eye-opening. At this point in time, we've got about 10 responses so we have enough material that we'll be publishing for some time. I'm still working with other contributors at this point as well. We've done written questionnaires, we've done interviews. We're here to work with the contributors so whatever makes them happy is good enough for me. But that is something that we've been working on and that will become real and live soon and later. So really excited and looking forward to getting those published. Next up on the agenda, so we have the version documentation site for Jenkins.io. This is something that Vandeet and Chris have been working on since Google Summer of Code. They've made a lot of work. They're getting to a really great point where the site is almost ready. And so they're looking to hopefully have this done by the end of November. So that's prior to holidays in India where Vandeet is based. And so Chris and Vandeet are working towards that. They also have, I think, they have a prototype site and these are all available as well to see. Yeah, so the link is here in the agenda. So you can just see how much work they've done thus far. It's great. I'm really excited for it. Yeah, kudos to them for all of their work on this thus far. Next up, so we did, we have the monthly newsletter that has been merged as of 20 minutes ago. We're a little bit more than that, so it's not live on the site just yet, but that will be thanks to all of the SIG leaders for their constant participation and contributions to that. You'll get to see our victories and our achievements just a little bit. Next on the agenda, so the LTS release again next week is our next belt baseline release so LTS 2.426.1. That'll be in November 15, 2023. The pull request for the change login upgrade guide is available here. That has been getting feedback and suggestions. I've been working on that with Mark to get that up to date and make sure that everything's included as much as possible. It does need to get an additional update for. Oh, the sneak ammo plugin. Okay. And Mark, I saw you were just adding this. So, was there anything to note on that or was it just a late backport that we need to make sure it's in there. Yeah, so, so the story there is that some security scanners make the mistaken assumption that if a dependency is included in Jenkins, Jenkins and that dependency has any vulnerability it must be reported and flagged. And then we get these bug reports to Jenkins.io saying, Oh, there's a security issue in such and such. We spend, we waste a bunch of time telling people, please read our policy about security. This is just a simple way to avoid some of those complaints. Hey, this plugin is already available separately it's been available for two months. And many, many users are using it, and it's running quite well. This is just a way to silence the security scanners. And yeah, so in terms of you'll need to add a change log entry for it there wasn't a change log entry added in weekly, because it's not actually user visible change right users won't detect that change. But I agree with Daniel Beck that anytime we do a backport, it needs a change log entry, even if there wasn't a change log entry for it in the weekly that included it. Great. Well, make sure that that's included in the change log as well. It seems like there's plenty of reason why it should be there, like you said. So yeah, that's fantastic. And I know there was a couple other changes that were not user visible that we did actually have to remove because I had included them. So it's nice to see the other side of this. Thank you. Appreciate that mark. And yeah, and just so everyone's aware of the release checklist is in progress for the release. This is something that we have for every LTS release. So this is always available you can check it here, but everything that's being done is being tracked as well. So, thanks for including that mark I forget to put that up here sometimes. Next up on the agenda. So, again, we are in November now. So, October fest 2023 has completed. We reported on this last week, but just again this week. So, for total number of pull requests created, there was 1029 total number of October fest PRs was 415 number of October fest submitters was 81. The number of validated heck over fest pull request was 356 in a validated submitters was number was 68. So, there is a trend you can see here in the numbers it is down from last year. This was felt across multiple projects, however, so it's not unique to Jenkins in that sense. The plus side of that is that the spam rate was that much lower this year as well, which made everyone else's lives easier not having to worry about that spam coming through not having to worry about junk pull requests or any kind of noise basically. So, while there was a dip in participation. It went really well. The work we got was fantastic and the participation and contribute contributors that put in work during October fest are greatly appreciated and yeah just thank you so much to everyone who participated and got something out of October and whether it was a tree digital badge or just a sense of accomplishment. And then Chris stern reported that he had great experience mark your look to have said the same so any closing remarks for October fest or any other thoughts that you want to share that. Oh, another no other items. So, last on the agenda I had for today was the ongoing update CLI discussion. So, we talked last week, Bruno about just having the log being merged so that's never merged. So we have that. And then, I know that we had talked before that they'll this other progress have been well it's in draft mode so it's not necessarily open but yeah it's still in draft mode I guess it's a follow up to the one that just got merged but I now have some merge conflicts I have to sort out before putting it up for review. The thing is, hmm, we are. I had made a previous PR a few weeks or months ago regarding using update CLI in order to have the right version of the Jenkins LCS in different parts of the documentation up to date. And I was very bold and I removed a Ruby script that was used up to now in to generate these pages. So we had an error and I had to reverse some parts of that so now I'm keeping the Ruby script just in case, but I think I replaced just in every part where it was needed so now it should work. It works quite well and if not we can always open a new PR and correct mark I think you were kind of puzzled yesterday because you saw that I was replacing some keyword that were used by the Ruby script. And that's because we keep the Ruby script that I hope we won't use it anymore. I think I saw one or two PRs yesterday regarding the update of the Jenkins LTS in the documentation. I don't know if they've been merged or not. I'm pretty sure they have not been merged so that was when I needed. So what what the obviously I wasn't paying enough attention when I merged the pull request I merged the pull request. Kevin the one that was not draft. And when I saw that it said exactly when I saw that it said that we rely on a Ruby script I mistakenly assumed that that Ruby was continuing but it is in fact not so what this does not not not your fault I didn't read it well. But it does a keyword replacement however, how does it survive then after the keyword has been replaced the first time, because the keyword is no longer there now. Yeah, so the Ruby script won't work anymore but just in case we wanted to revert my PR it would work again I guess. My question wasn't wasn't how the Ruby script will work it's how will the update CLI script work. For those keywords, it's looking for the words, the words that are around this part so I'm just looking for something before something that looks like a version and something after something that look like a version and then it makes its magic with regular expressions of course we do love them when they work. So that's the way it works and of course that makes the Ruby script. Right, okay so then then what that says is, Kevin we do need to merge the one that I had put a put a question on that changes the, where is it. We'll have, maybe this is it. Yes, this is it. Yeah, this is it. So, so this one is the one that we need to just remove my my objections merge it, and this will give us the experiment experience to see does the update CLI do what we expect and if not Bruno Bruno can work to resolve it. Yeah, we haven't even if you'll click that refresh over on the right hand side yeah that way. Thanks. And then I can, because if ultimately this the benefit this gives us is now the version number is literally inside the source file instead of a placeholder, and that means that when we go to version documentation in in the future, thanks to the Google summer of code work and Chris Stearns work. These numbers will be expressed exactly there rather than as placeholders. So, so build time content generation would be removed for this case and instead replaced by take the content straight from source control. Yes, you're right. We still have some problems though because I had made the first PR that gives a general message about let's move, you know, let's bump the Jenkins version image on various parts of the documentation but the thing is, it is also changing the volume of the bomb. And the one that is still in draft will address that will have two separate PRs one for the Jenkins LZ versions and one for the bomb versions. So, maintainers of this repo will have a clearer idea on what is this PR trying to do, except it will change from a more global message that was misleading. Yeah, that's why I was trying to explain. Thank you Kevin. Yeah, and so this would go another step in making sure that those updates are more clear when they're actually being generated and from the PR is basically Okay, so then Mark is there anything else that we need to do here or just removing your changes is enough in this case. Yeah, just marking it for your requesting my review is good enough. Okay, cool. Great. Thank you very much Bruno. You're welcome. Thank you. Thank you Mark for helping clarify that. So that covers everything that I had on the agenda. Is there anything else that anyone want to add or discuss today? Not on my side. Nothing for me. Okay, great. So then we'll go ahead and call it there. Reporting will be available 24 to 48 hours and always thank you for joining. Thanks for watching. And we'll see you next week. Take care until then. Thanks. Thank you. Bye bye.