 Welcome, it's documentation office hours. This is the first day of September 2023. Thanks for being here. Topics that I had on my list, quick overview of blog posts, brief discussion of Google Summer of Code. We were hoping that Ostrichosh might join us. And then some leftovers from previous sessions about plugin bill of materials version, Java 11, 17 and 21. And that's pretty much it of topics that I've got. Chris, any other that you want to add? Maybe for guisness of code, and I'm thinking like, oh, maybe it's good, yeah. Okay. So those two topics are sufficient. I think so, yeah. All right, good. Okay, and I've got one Mark show his picture, draft form. Okay, good. All right, so let's get started then. We've got three blog posts that have come in in the last week, one from Bruno Verrachton on his experiences running Jenkins on risk five with Java 21. And then we've got a blog post from Ashutosh Sassena for Docker compose summaries. And another one from Harsh Pratap Singh on his results with GitLab plugin modernization, thanks to all of them. Google summer of code. Anything you'd like to highlight there, Chris? Maybe we should highlight, we have like the Docker company's project success we completed, even there's like all the other items in scope where like we have been done to start this section, but so it was good progress on why. Well, if I remember it, it's four or five tutorials that now execute with a single command, right? And then in terms of remaining work, we've got to create a Docker container repository on in Jenkins Infra and we've got to create a Docker, what would you call it folder on Docker hub and create jobs to maintain those containers. But it's already got, already has the maintenance configured just not yet running on CI.Jenkins.io. Great, excellent. Yeah, this is, I was just reading comments from a user who was saying, hey, such and such a switch doesn't work in the tutorial. And it was one of a long and involved set that is now completely removed. Once we get this finally integrated, it will be gone and they'll just type Docker compose up. And much better, much, much better. Yeah, agree. All right, anything you wanted to note on version documentation and Vundit's progress? Yep, so it's like, I think we have finally have like an almost workable function, a draft for the entire site, except for the pages we haven't implemented with Gatsby. Hmm, okay. Because like some of pages will be implemented in Gatsby and those need to be integrated into the whole website. And we have like abandoned idea of using a Strapi backend even though that was waste during the discussion before with the community. So we're going to simplify the process. So we're going to retain the existing reviewing process for blog posts. Oh, okay. So you'll use GitHub? Yep. Ah, very good. Okay. I like that. That's, I like the simpler, the simple approach. That's, that's great. Excellent. Yeah. Any, any concept of what are the next steps? Next step would be to focus on a checking there and tour site lines. Seems like we have fixed most broken things previously, but from previously, but then my, I think we're going to have to, but there might still be some broken links somewhere. So we have to check them because I check with, I check with, check with Band-Aid and he told me like the only thing that we currently have for automation is the logs. But that would get started except like, we'll have to analyze like what's in the start or what's in the logs. Good. Okay. So the logs give us some report of broken links or. I'm not sure. I knew, I knew, I knew found out more because I, when they didn't say much about the formats or like, what kind of details we can claim them, the log files, but. It seems like it might be possible to automate it later on. To check for like anything broken. Good. Very good. Well, then certainly there are, there are automated link checkers. So that's a, that's, that's happened. We've done that before and in generated long list of, oh, here are a bunch of broken links from Jenkins.io already. So I think I see good hope for later automation, not required immediately, but good, good chance to apply it later. But for now, like we have to check, like we'll have to split like all the, all the links between us and we'll have to check manually. Right. The due date and in September. Okay. Good. Very good. Okay. Anything else on version documentation. Um, I think. Well, I think for the project, like we might be able to complete like, um, all the milestones we were set out to do. At the beginning. Congratulations. It might be able to because like we, the block is now easier to do without the strappy backend. Ah, right. Okay. And. By not using the strappy backend instead staying with GitHub. You've you've simplified. I like that. That's great. Yeah. Okay. Yep. Anything else on the topic? No, but, um, she wants to talk about the other two projects, like maybe get lab modernization and last time. Get a plug in. Yeah. Modernization. Okay. And also, um, and also for, for the, for the health probe. Yeah. Yeah. So if I give that fucking modernization, we're still weighing on the results for the interactive tasks. Yeah. So that's, that's my. Interactive testing by Mark weight has been delayed by work. Yeah. And needs more testing. More. Comparison of old and new behavior. Right. So. Exactly. And see the test outlines. That are in the project in the project meeting notes. Okay. Good. Anything else on get left plug in modernization. Nothing else except it's been concluded. Successfully. Right. Yeah. Well, and, and positive note for me is harsh. Has agreed to continue as a maintainer. Right. Yeah. Yeah. And that is a first. Hi. This is the first time that I know of anyway, when a. A contributor. Became a maintainer. So congratulations to harsh. Yeah. And he did you want to cover plug in health score next. Yeah. We should talk about it a little bit because like, um, I think like there was. I saw like some discussion on, on get to perform not sure if it's like related to the work now, but. Um, I think. Yeah. I'm just imagining of like some kind of an issue and do let me check because. Thing was having to do with, um, Like the score being like, um, Like the ways calculated is not like not ideal or something like that. It was like, um, on GitHub before they see that. Hmm. Okay. Well, I know that I know that, um, I know that Adrian was working out and was, was working on. What I'd call a code refactoring or a code improvements. That that may help to grudy's word. Okay. Yeah, but, um, Let me try someone new. So. How can you have a scoring? Is there the project? Uh, is like that was an issue with us for at a pro for fair and both on default branch. So that might be a possible direction to a future. I contributed to work on. Ah, okay. Yeah. You say, and that's identified in the chat channel. And the guitar. No. Okay. Good. Yeah. So it's in the comments of a poll request or. It's an issue, I think. Oh, okay. Good. Alex. Oh, very good. Okay. Yeah. So that's one more pro to work on. Very good. Very, very good. Anything else you wanted to note on plugin health score? Um, I think it's. Like it. So we're going to like it. I'm not sure. I'm not sure about. I don't know. I don't know. But it's a quick progress. Cause like, um, She was, she wasn't being that clear last time during the meeting. Except like, she's like, um. She's working on a third party. People. Again. And, uh, it was, uh, with. For a while because there was an issue with. Um, how to get to third party. Okay. Yeah. All right. Yeah, but I was thinking like for Fujikide's project, like, so I'm not, we'll need to check on the documentation for that project, because like, I'm kind of having the feeling that we might need to add some docs to the work. Okay. Maybe Asia will handle it, I'm not sure. So that could be like a hack to the first project idea. Yeah. Yeah. Consider it for Octoberfest. Good idea. Yeah. Very good. Oops. Okay. Yeah. My fingers. Okay. Apparently I'm tired. Okay. Resting my fingers on a keyboard. Okay. Anything else to discuss on plug-in health score? No. Okay. Okay. So the next one was on describing how to choose the bill of materials version and no progress since last week. Sorry, but none. Okay. However, I spent several hours working on the next one and I wanted to show this to you to get your right insights and ideas. So what we've got is we've got Java 11 reaching end of life in October of 2024. Java 17 has been well supported and Java 21 coming online in mid September. And what I was looking at is trying to find a way to describe a proposal for which version should be supported when. Oh, I need to hide some rows. I've got my worries about. Here we go. Let's do this. Let's hide the product that I was worrying about. For now hide that. The CBC I think is a cloud beast product. Okay. And so I, I have to be sure I think about them, but in terms of community discussions, we don't have to worry about them as much from the community side. Yeah. Okay. So here's the picture. The idea is. Today. Java 11 is required and that's the blue color and Java 17 is supported. And it's been that way since March of 2022. And we'll continue that way all the way until Java 11 actually reaches its end of life at the end of September 2024. Okay. The, the reasoning there was we don't want to end that prematurely, but we can't support it after Java after open JDK stops supporting it. Yeah. So then we have to transition. And my initial proposal had been, Hey, let's make Java 21 be required. But the feedback I've, I've received from the cloud beast enterprise customers is no, we need to have this transition to Java 17. But what Uli Hoffner has noted and Tim Jacome is, Hey, let's simplify this where we can and not, not spend a lot of time supporting three Java versions all at the same time. So that's why this is trying to get us to a, a state where given a six year lifespan for a Java version. So Oracle releases a Java version and the open JDK project takes it up and they'll support it for six years from its release. So 2023 September goes until 2029 for Java 21. So that's this green bar here. The idea is let's set our goal that first two years of that six year period. The new Java version is supported, but not required. The second two years, the new Java version is required. And then we drop the support of that Java version completely in the third two years. So that we're keeping only two Java versions at any one time. We're not carrying around the baggage of three Java versions. But in order to get there. With this two, two, two split of the six years period, I had to compress Java 17 support, required period to only 12 months and Java 21s to only 18 months. Comments, concerns. Yeah. Some were concerned about those, but like, but period, like when the versions are supported, because like, there might be confusion for users. Tell me more what you mean there. I'm not sure I understand the question. So I just want to ask a question first. Like for Java 17, for example, it would be required for from March 25th to September 25th. Yeah. So, so from March of, so we will, we will, we require Java 11 today and we'll continue requiring Java 11 all the way until the end of September of 2024. But what about Java 17s? I see it's fully supported Java 17. This yellow color is trying to say it's fully supported. It's just not required. What about between March 26th and March 27? During, so at the end of once we reach October of 2024, open JDK no longer supports Java 11. It all is fine, it all is fine. But 17, 21, 25, 21, I see like a pattern. It's like there's a period when the log version is required, but after once it's as unsupported. Oh, right. And so the reason. So this you're, you're asking why this red zone here? Yeah. Okay. And the intent there was that if we don't make that red zone there, then we end up during the period from say March to March, this 18 month period, we end up supporting three Java versions, 17, 21 and 25. Okay. So that's the only reason. Right. That was the only reason is to avoid supporting three Java versions at a time. Okay. Okay. I can see like some people may not like it. Absolutely. Right. That's they certainly they're one of the challenges here, right is balancing the, the needs of the users and the needs of the developers. And that's, that's what this is trying to strike a compromise there between. Hey, the developers would just as soon support one Java version and not have to do too. But the users, especially enterprise users say, Hey, we take a long time to move from one version to another. Yeah. You've got to, you've got to support us longer than, than your developers are, are saying they'll do. I think so. Yeah. So the idea is we'll use a transition period where Java 17 won't use the two, two, two. You know, two years of supported but not required two years of required two years of unsupported. It will use one, two, what is that? It's, it's like three years of supported but not required a year of required, and then two years of not supported. Then Java 21 will extend the required period 18 months to 18 months. And then we get to 25. We're now in the cadence of a year of supported but not required or two years of supported but not required two years of required. And then two years of not supported. And then if, if the project said, oh, we want to make this, that Java version that was required supported for longer, that's an, that's an option we have, right? We could delay requiring a new Java version if we wanted to. Yeah. Okay. Any, any other concerns or comments? No, let's do a concern. All right. That's, and that's, that's the top, those are the topics that I had for today. Any other topics? No. All right. Let's call today done. I'm going to get some early sleep. Okay. Thanks, Chris. You're welcome. Bye. Bye.