 Welcome. This is the 12th of August 2022. This is Asia Jenkins documentation office hours. Topics for the agenda today include action items. News. Change log. Google summer of code. Longstanding poll requests. Any other topics anyone wants to add to add to the agenda. Okay, let's take those then so. First item action items. No progress from me. Oh, I take it back. She called Africa contribute on results blog post is done. And posted to Jenkins.io. So let's get that one really quickly here. It is here. And this one. Okay. So by way of news, no other progress on action items other than those. By way of news. Jenkins 2.346.3 LTS release this week. There will be a broadcast tomorrow. What's new in 2.346.3 with Darren Pope and Mark wait. Or tomorrow tomorrow's the wrong broadcast. Yeah, tomorrow roughly in less than 24 hours. So tomorrow is a relative term. It'll be my Friday. And we do it. And we go forward. Any questions on the news or the action items. Okay. All right. Next topic then was Jenkins 2.361.1. That's the September. Change log upgrade guide and blog post. And so this one Kevin Martin's. Has started the. The review process. Ford of the of changes since. 2.346 baseline. And what we did is he and I sat together and we did a yellow highlighter. On each of the items we thought should be a tent included. And that's a that's always and. That's a really important thing. And that's the human activity. We have to decide because the collection of. Changes is much greater. The sum of all weeklies is much greater than we want to show users about an LTS. The. Back. Backport results. Depends on what is selected. For backporting. And so the backport section. We have a. Several LTS candidates. In Jira. And if I bring that up, I can show the. The results of that Chris, are you reasonably comfortable with how to do the LTS candidates query? Not really. Okay. So here I'm going to bring up. Here is the LTS candidates query that I just ran. And so Meg, I should let you know, we should have introduced Chris. I'm sorry. Meg McRoberts is a long time documentation contributor. I'm a documentation contributor. Chris Stern is the release lead for Jenkins 2.361.1. Oh, nice to meet you Chris. Chris is also a Google Summer of Code organization admin. And a previously successful Google Summer of Code. Student to another project. So this year he is mentoring. The project on Jenkins file runner as a GitHub action. In addition to being an organization admin. So. Thank you very much Chris. All right. So the LTS candidates query. This thing tells us which things are potential. For inclusion in the LTS. And if we look at those candidates. We should see for instance. This one as one example. 2.361 core sources and Java doc are not on repo.Jenkins.io. This one matters to me because I don't want to miss having the, the source code available and the Java doc available. It breaks our documentation generation. Okay. And so what you do is you go through that list. Looking at them saying, okay, which of these should be back ported. And there are some crucial ones here like. Oh, where is jetty? Oh, that's interesting. So the jetty one is not in here yet. And it should be. So we need to find out why it's not. So topic for investigation, the jetty 10 upgrade. That was included in 2.363 should be an LTS candidate. Let's see if we can find that. See why it's not listed. Jetty 10 Winston 6.1. Here we go. This is LTS candidate. It is closed. Released as to why didn't I see it in the query? How come is this like three, six, three, but not three, six, one. Oh, because, because it wasn't ready in time for three, six, one. Oh, this one was read that's, and that's what a back port is in this case, right? Is something arrived in a weekly after three, six, one, but we want to apply it to the three, six, one base. In order to be sure that's in three, six, one dot one. Okay, I see. Yeah, so now, but what I don't understand is, oh, right. This thing is shown as new features. So I need to change this to improvement. Satisfy that query. Okay. Good. I don't think possible mind that I changed that. So now. Now we see the windstone thing. So here it is. Cool. And this query that I linked is actually in the LTS checklist. So if we, if we look at the checklist. Just a minute. And Chris is the one who made Chris is the one who created this checklist. So, so he used a template that exists there and. Let's see where is the LTS candidates query. This one update Jira labels for LTS candidate queries. LTS candidate issue. So here's the query. And we see. There's that windstone one. And as you're selecting them for backport. You'll, you'll update their label here on Jira. So here it says use version number dash fixed. If you decide to include it in the, in the backport. So two dot three 61. One dash fixed. And that means you've put it in the backboard. Or if you say, I am not including this one. I recommend against it. So here it says use version number dash fixed. If you decide to include it in the. And I recommend against it. You put two dot three 61. One dash rejected and you leave the LTS candidate label. Okay. All right. So, so there we've got. The, the candidates and the, let me put the, this thing's link. Good. Okay. All right. So any question. I guess back to the topic at hand, the changelog. So Kevin has started this review process. Items for inclusion. And then this backport section is just generated. Generated by Kevin. Once the backports pull request is submitted. And Chris, you're the one who. Who submits the backpress backwards pull requests. Okay. And if you check the checklist here, it talks about open the backporting PR with this information. You can use this script. And this query to do it. Okay. This will help you and, and for examples. If you look in the. Jenkins core, you can see examples of others. Backport pull requests by looking in the closed pull requests. For the keyword. Backport, I believe. That doesn't, that's, that's not as helpful as I'd hoped Chris. Always. Oh, backporting. Okay. Backporting. And now, if we looked here, backporting for LTS 2.360. 346.3. Here's an example. Okay. Right. So, so. Any questions on the change log part of this. Then the next piece is the upgrade guide is assembled. So Kevin is also assembling the upgrade guide. Okay. And the way he does that. Is he reviews. All pull requests. Submitted. To the 2.361.1 baseline, if you will. And looks for. Find the upgrade guide needed. And if the submitters. Did what they were supposed to do that label. Will be there and we can just rely on it. Now the reality is. That's not always the case. So what he'll also do is review. Every one of the pull requests. Looking, is there an upgrade guide mentioned. That. They forgot to put the label on. So what he'll, what he then finds is here's one that has the upgrade guide needed. And here's the upgrade guide entry. Any questions on how he's going to assemble the upgrade guide. I'm not sure. I guess like. Would that be a final version coming out like as a guide as a dog. separately. It, it does. So the, yeah. So what happens is. Let's, let's look at how it's presented. Maybe that'll be the good thing to see. So on the download page. There are three links here. Okay. Two over here in the three links are changelog upgrade guide and past releases. Okay. So changelog. There's the LTS changelog. So let's put that link there. Then the upgrade guide. Brings us to this page where what he'll do is he'll create a new top level entry for. 2.361.x. And the upgrading to 2.361.1. Thing and it will look like this. And those things are actually represented. In the, by a very specific file name, et cetera. And that's how they're expressed. Okay. Then. So any, any other questions on changelog or an upgrade guide. No. Okay. When they would be released. So ocean. Yeah. So good question. So the. The, we like to make the changelog and upgrade guide. Are usually available. When they are released. They are released at least one week prior to the release. Okay. They, they don't get merged. They are usually merged the day of the release. No, no, I take it back. Usually they're merged. Several days prior to the release. Okay. They don't become visible to users. Until the code is released. Okay. Okay. So the next piece is blog post. And this is, it's not always required. But this one is big enough. That we think we need a blog post. What will, what it will highlight is. Require Java 11. And all that means. Right. So. Okay. Upgrade your agents. Upgrade your. Your agent JVM upgrade your. Upgrade your controller JVM. Etc. Check your. Evil job type. Sorry. That's affectionately known as the maven job type. And, and understand the impact. Etc. Then we've had a request from the continuous delivery foundation for a higher level blog post. And, and so it's. We're considering how should we approach the higher level blog post. One idea that Kevin and I discussed in office hours, Europe earlier today, or. Yeah. About 12 hours ago. Was that we consider. A history of Jenkins improvements. With things like. Tables to divs. Two dot two 77. And then UI. Improvements phases. One through four. And then Java 11. And et cetera. We could even consider the transition. Historically. Java eight. Etc. So Java 17. And, and that. That's when we're considering. I've got to talk more with Fatih. Digi. Menchi. About it to see. At what level. He said, give us a highlights thing. A high level concept. What about any of the security improvements? Is this for the last. Oh, yes. Yes. Good idea. Very good point. Security. Security enhancements. Defensive things like. Yeah, good. Like you can't turn off the. Agent two. Agent two. Like you can't turn off the. Agent two. Controller. Exactly. Those kind of things. Yep. Don't necessarily want if there's vulnerabilities, but you know, just general stuff. Safeguard's right. Content security policy. Preparations, those kind of things. Yeah. Have they're trying to think. Were there. There's some performance enhancements. I don't know. I don't know. I don't know. I don't know. Somewhere. May have been that one. I'd have to look further on that one. I don't remember. Yeah. Try to remember the whole long, long arc of it. Right. The UI. Which was so big. They, they have been big. Anything else on Jenkins 2.361.1. Chris, any questions from you or, or topics you'd like to be sure we review. I think I'm good for now. Okay. Great. Next topic then is Google summary of code. So Chris, maybe this is when you want to address how do you feel that's progressing, et cetera. Okay. So, um, we've just had a call yesterday. And we had three contributors. As a call. So, so far so good. Um, I think they're all on track. So you can see it for your expedited line. And, uh, Me term revisions have been done and all past. Which is good. Very good. Thank you. Now. In, in office hours, about 12 hours ago, one of the Google summary of code students actually showed some additional demonstrations of progress they're making. So if you're okay, I'm going to show some of the things they highlighted for us. This is Vihon Thorough. And Vihon showed us, um, hey, the issue we had detected in the documentation that was being generated is now resolved. And, and it's a nice, nice feature. What had happened was Vihon has significantly improved the document, the pipeline steps documentation, but in the process, we lost this particular page. You can see by my clicking here, it's back. So one of the things that, that this gives us, Vihon's enhancements gives us the ability to filter on page by just typing a little bit in this field. This is so much better than the old way we had to do it of search in page with control left. This is just much, much better. Well, Vihon's now found started his work on the next step, which is to dramatically reduce the size of this huge page. So that it's some of the things that are embedded in inside it, like this monster right here, um, become separate pages for faster loading and for removing redundant copies of this thing that exists in five or more places in the documentary. So, so it's a, again, he's making great progress on, on how it's going. Yeah, it's cool. So, and I'm just going to copy those notes from earlier just to be sure that we've got them. Great. All right. So next topic that anything else on Google summer of code that you wanted to highlight Chris. Thank you. Except for everyone's projects under Jenkins right now, except for the one I'm having, but we're working on that. Oh, good. Okay. All right. Next topic then longstanding pull requests. So we've got, we've got several longstanding pull requests open on Jenkins.io. Let's take a look at those. The one that had been receiving. More attention recently was. This one right here, where is it? Here it is. The improve a plug in tutorial and blog post. So what, what this is, Chris, for your info, it's a, an attempt to make it much easier for new contributors to join the Jenkins project and readily make useful and valuable contributions. To the project. So here's how the page will, will look when deployed. Is it will look like this. They go to the developer guide. And this thing on improve a plugin is the new thing. And what it provides is a series of steps with video links on, Hey, here's how you add a Jenkins file. Here's how you update the parent palm. Here's how you update the minimum Jenkins version or add more of spot bugs or use the plugin bill of materials. Each of these things is a, a small but actually useful contribution that they can make. We hope we'll be able to use this for Hacktoberfest for a new plug-in adopters, et cetera, so that they can, they can take these things and run with them. Now, many of them have video clips that highlighted that Darren and I recorded some time ago, how to do this particular thing along with the step wise instructions. Okay. The challenges it'll, it'll require continual, continual evolution. Right. This one, for instance, migrating plugin documentation. There's a lot of material here about how to do it. It just has to be organized properly. Okay. Maybe I can help out. Yeah, that, that would be, that would be much appreciated if you can, that'd be great. So right now the next steps are that. Let me put a link to that site. Because there's no reason we can't prototype. And the original document and the prototype, Kevin Martins has agreed to, as a brand new user, as a brand new contributor, he's going to actually do an evaluation of it, walk through its steps and give feedback. Hey, this didn't work for me or this did work. And then we are also going to use that same material at DevOps world in a 90 minute workshop. That Mark wait, let's see. Mark weight leading Bruno, they're Austin and John Mark Mason assisting. And what we do is what we hope there is we'll get several people who will adopt plugins as a result of this workshop. Okay. Make any questions from you there. I know we've been through this one multiple times. So we've got some requests from you and no good to see progress happening. Okay. So other long-standing poll requests, we've got. One from Meg that we still need some review on. Actually, we've got several from Meg. Meg, I think this was the one we had worked on last week. Wasn't it? I think so. Yeah. The major restructure. Let's be sure that it doesn't have any new conflicts. Okay. It doesn't have conflicts. So that's good. There's a comment. I think that's an old comment that I disagreed with. There's a comment that shows here. Okay. Hang on. Let's see. So you said way high. It's early. We'll see there. Let's go down. I think about half a page. Okay. There it goes. Okay. Yeah. So that's, I think that is resolved, but it didn't resolve in a way that actually automated. Okay. So it's because it's certainly showing outdated. Yeah. Okay. You look at it and you look like it looks like it's not stated. Can we say that when it's resolved? Can I've, in general, when Daniel comments on things, he's his preference has been don't resolve it because he likes to read the history. Okay. So we'll leave it. Yeah. Okay. So. But I think that. The restructure here now we could. And we may want to, because it was, we lasted the merge seven days ago. Meg, maybe what we should do is let's update this. And. Get, get it merged into get master merged into it. Yeah. Good idea. So that we don't, we don't get too far distant from master. Right. So just a minute. Let me. GHPR checkout. The one we need is this one, 4612. Okay. And how many poles? Okay. So it's, it's now up to date. Good. And this will now regenerate. The, the, the preview site with. Current changes of the site itself. Plus your additions. Right. Now, are there others of these that we should do something similar? So. It's all getting so rusty now. I'm trying to remember. Well, maybe let's take a look and because several of the others were like smaller pieces that would go in after this one. Okay. So they, they really are, and that makes sense. They should be dependent on the, on the restructure. Right. And three or four of them are just work in progress. And then we start. They were thinking we can have information on. Right. Okay. So, and worrying about the work in progress is probably premature. This one is the big one. And this is the, the one that we want to be sure Daniel, Daniel gives us a review on others in the security team. And then the other things. Just for Yaks and Grin since you're doing. What is in that? 47, 0, 1, the security for plugin developers. Is there anything in there that we want to be sure is in your. Well, let's see. Good. So this one has. Oh, okay. Right. So watch the security advisories. Confirm to the security architecture. Yeah, this is a good one. All right. We ought to consider. These are, these are points of advice for developers to consider ways to write more secure code in Jenkins. Right. And that does go to developer. Does that go into what's. So this goes into developer, but it would not naturally go into the tutorial unless I put it there. So that's a good one. This is a good one for. Let me put a link to this. Into the notes so that we. Consider including security. Recommendations from. PR. X, X, X. 47, 0, 1, I believe. Yeah. Okay. So 47, 0, 1. Okay. Good. Thank you. Is that would need to be refreshed then and. Oh, we should do that. Yeah. Good idea. So let's do, let's do that. GR PR checkout. 47, 0, 1. Get merge master. I recall. That's somewhat nascent that there's probably a lot more, but it's a start. Right. Good. All right. Any others that we should, we should review in that. Let's take a look here again. So back here too. Or here, you know what? Let's make it easier. Let's just look at. Ones with you as the author. Okay. So. Yeah, it really shows it. The most crucial is the restructure. Right. Now, why did I request changes? Huh. I don't know. Interesting. I think still the. The, I've got to review it. And Daniel, I think Daniel's is the more crucial, but let's. Yeah. This thing, which you're so many iterations. Mm hmm. Um. Yeah. I thought it was a kind of a good place. Now I don't know where it is relative to what's happened since I. I haven't really worked on it. So. Right. Okay. Security section restructuring. That's not how I wanted it spelled. Okay. Okay. Back to our others. Any other. Older pull requests we should look at. So let's look at. Pull requests in general. Oh yeah. So here's one. Okay. This one is one that's probably large enough. It needs a separate review. Kevin just submitted this one as a. An update to the blue blue ocean pipeline editor document. But it's one that, that it's been through a review by several other reviewers. I just need to do an initial review. If we look at the review comments, there have been. Comments and refinements from, I think from Carrie and from Dan. Yeah. So from Carrie Mason. Okay. I don't see any from Dan, but, but this one has been reviewed in depth already. I just need to do a final review and get it merged. Yeah. Okay. Good. So notice Meg, there are only 24 open pull requests. Wow. Under the one page of open pull requests. Wow. So. Any other topics we need to review today, Meg, I know you're usually at the end of your time about. I am. I'm just about ready to hang up on you. All right. Chris, any other topics you want to cover? Yeah, but it's more like a question because I was going to ask anyways later. So I'm just wondering when would the plugins need to be upgraded to like to drop support for version eight of Java. Oh, good question. Yeah. So when do plugins need to be upgraded to drop Java eight support. That's a very, very good question. So let's talk about the how it, how that works. So when a plugin requires a Jenkins version. That requires Java 11. Then the plugin also requires Java 11. So as an example, when the get plugin sets its minimum Jenkins version to 2.361.1 or later, then the get plugin requires Java 11. Now that's important. That specific example, I'm going to reshape it just a little bit. The get client plugin sets its minimum version, then the get client plugin requires Java 11 and can upgrade its internal copy of J get from 5.13 to 6.2 or later, because the J get project stop supporting Java eight with 6.0. So we've been locked on to J get five, because we don't we still had to support Java eight. As soon as the get client plugin requires Jenkins 2.361.1 or later, I can upgrade J get to 6.2 or later. Okay. Did that answer your question. Yep, it is. Great. Any other questions. Nope. All right. Recording will be available. I hope within 24 hours for reference purposes check for it on community dot Jenkins.io. Thanks everybody. Thanks. Talk to you next week. See you. Bye. Oh, oh, Meg, Meg, wait a sec. Sorry, I forgot. Next week, I'm off because I'm going to be in the mountains of Utah. So I propose we cancel next week's meeting because I don't want to make somebody else try to run the zoom setup for this meeting. Are you okay if we cancel and Chris is it okay with you? It wouldn't be a meeting without you. I just couldn't stand. Yeah. All right. Okay, thanks. Next week. Does that leave you. You don't have any deadlines that are going to be hurt by not having a meeting, right? No. Okay, good. So glad to have you on board Chris. Me too. All right. Thanks everybody.