 Welcome, it's documentation office hours. This is the 4th of August. Thanks for being here topics on the list include Google summer of code. Open pull requests of interest. DevOps world tour and possibly canceling the meeting August 18th. Any other topics you'd like to add Chris. Okay, so let's talk to Google summer of code first. Version documentation for Jenkins that I also, as I understand it, Vandy will do a demo. Demo the, the status at UX, the 14th of August is that right. 60 August 16. Yep. Great. Now I apologize, I won't be there I'm out of the office that day. Congratulations. That's great. How's it going? What do you want to show us a demo? Do should I let you share the screen. Maybe not today because like there's some issues with the effects. Because I still chase Vandy to complete like, before into a demo. All right, no problem. Because I think there's some broken lines to do as of understanding, but not, not sure. Okay, some perfections. Great. So let's see us. If I look at Vandy. That's here if I remember right. And so here's 2.1 and two. Okay, so, so versioned is working. Good. Very good. And edit this page takes me to his page. Nice. And still the much better expansion and contraction on the left. I do have some questions about like, what we should do regarding existing versions. Because we have to come they all up to where. When you say existing versions you mean what should be in the pick list here. Yeah. Oh, see, and I would think we own, we would say. The only baseline of LTS versions would be my assumption. And maybe then only the most recent one now, just do 2.401. And call that good enough. And then when 2.414 releases, we could create a, create a snapshot or create a branch for 2.414. I wouldn't, I wouldn't do more than anything finer grained than, than the long-term support releases. Okay, cool. Yeah. It's a good question. So, and that's certainly a good question to ask in the. How many versions. Should be in the documentation in the list of versions. Or maybe we say it this way, which versions. Should be in the list of versions, right? Yeah. And my thought was. Mark thinks. LTS baseline. So 2.401.1. 2.414.1. Dot, dot, dot. Or maybe it's 2.401.1 represented by. 2.401.x. Okay. Yeah. You know, that's, that's the concept. Dot one is probably more accurate because we'll certainly take the snapshot. We'll create the branch at the dot one branch. But it'd be understandable to say, okay. Dot X. That would be fine with me either way. Okay. So I. Weekly seems too frequent. And. And won't have many changes between wouldn't have, would not have many changes between branches. Okay. Because we're not. We're not evolving that quickly. And if we look at. Command like it, they release every three months. And when they release every three months there. Their documentation has, let's see, let's go look at the reference. So here's one. Yeah, they do. Oh, they, they do. They do even their dot releases. So they do even dot. Dot two compared to two dot 37.0. Interesting. I'm, I still think. LTS baseline would be enough. May. What, what we're discussing here is this is Vandit sings. Google summer of code project proposing to rework the Jenkins documentation so that the user handbook is versioned. So we're up here in the top right hand corner, the 2.1. Let's make it big enough to read the two point run here in the top right would become two dot 401.1. And 2.2 would be two dot 414.1. So that it matches with the long-term support version numbers. The, the thing we're trying to match is something like what command line get does with their documentation that is has been changed pages for their documentation. So I can always go back and see what was two dot 25 actually doing. So question Meg for you is. Do you think it would be okay if we just limited this to the long-term support version so that it won't change more than about once every three months. Oh, you're muted Meg. Shoot there. Can you hear me now? Yes. I'd be comfortable with that. I mean, we don't, we don't have that many changes, right? That. Correct. And it's, I'm thinking that in the last majority of the cases, the changes to the docs for release aren't related to software that changes. Right. They're just improvement. So yeah, that's. It's always, I mean, it's a temptation to be really, really precise about it, but also that becomes mind boggling that I, you know, it's a lot read easier to remember 2.1, 2.2 versus 2.138.3, you know, or something, the longer numbers. Right. Well, and my worries is if this, if this menu has. 150 entries in it. The reader will get lost. Right. It's just too many and already with for a year. If we, if we were to do all of them, we should not. I think we should just start where we are. But if we were to do all of them, we would have. LTS is what that would be 10 years at four per year. So this would be a 40 entry. 40 entry menu. So that, that would still be a very large menu. And to look at gets theirs is probably 20 already. Yeah. Yeah. I'm thinking we should cap the number of versions available on the drop down to that. That's probably another good eight. Well, and, and I like their pattern here. I always this one. No, I thought I'd seen some version documentation sites where they'll give you a, we'll show you the first five and then give you a more link or something like that. Now you are looking at the reference stuff essentially man pages. What is it? They've got a book thing. What are they? There. So the book actually is a real book. And so that one, I'm not sure they do. It's, this is, this is a representation of a published book. Okay. And so it's, this is a physical book that they, for whose source code is intentionally open source. So they actually do not have like how to, they don't have guides as part of their documentation. They have the reference. Well, they've, they've got the book. And the book. The book is, and the book is very much a how-to. Right. But I mean, it's a published book. It's not like online. Well, it's also available online, right? You can get it as a pub or PDF or read it here. But it's not being updated with each new release. Yeah. Well, right now it's on its second edition. So, so yeah, there, the book has, has had, had multiple revisions. And I assume every, every so often. So right now it's, oh, it says it's 2014. That's pretty badly dated in the world of get. Yeah. Yeah. They've made major improvements since then. But I see that. I mean, that's, that's an old theory that I subscribe to. You do these reference things and those you keep up to date. Also because it's a fairly small effort. If you add an argument or, you know, rename those, you know, you can do that pretty quickly. It's not like rewriting prose. It's very clear. And so this is, if you really need to know the up to date stuff, you go to the reference and then the other is conceptual. Get the big picture. And that certainly matches. The book is very much conceptual here and the, the reference materials are, are very detailed. Uh-huh. As they should be. Okay. Good. All right. So. Uh, so Meg agrees. That. LTS baseline is enough. Thus. Four times per year. Which will still, and then recommended, or is there a way. That we can cap. The number of. Releases initially displayed. Well, not just initially displayed. We're assuming that the world goes on. Right. Okay. So, I mean, if, if we say no more than four releases, what have we got for now? We're going to say we're going to do four releases now. What are we going to have in a year and a half from now? Yeah. Are we going to, as we add a release, are we going to take one off? I assumed. I assumed that. Oh, go ahead. No, I'm done. So Mark assumed, keep all the versions available. But only show a subset in the menu. Allow. More or something like that. Now, no idea if that's even possible in Antora. I don't know how what, how Antora thinks about this. Chris, do you have any idea what does Antora do with regard to many versions? I'm not sure. Probably have to do some manual. Okay. Great. Any other topics or questions on the version documentation for Jenkins.io. That is a concern actually I would put in as we go through implementation to keep an eye out for how much of this becomes a manual effort. Because it seems to me it's the sort of thing that really needs to be. You know, I don't know if it's automated or maybe that changes how much you do it. Well, so when you say, say, manual effort, I'm assuming Chris, maybe you can, you can certainly help. I've missed the, the presentations that I've on date. With vacation and whatnot. Is. Is it dependent on just a branch and then it will build everything from that branch. So 2.1 in this example. I think so. Yeah. Okay. Excuse me. So Meg, I think, I think to answer your question, how manual is it? It's easy to create a new branch. We just. Get check out minus B of the branch and then push it to the central repository and probably add an entry in some configuration file that says read from this branch in addition. Yeah. I don't have, but I don't think this is reasonable. Is a star for a release where this document changed from the last release. Okay. So, so some indication of. I mean, I have one of these things rewritten for five years. You know, just to know that at this, this thing changed at this. Yeah. And I don't know if Antora's got such a concept. We've, we've intentionally been guiding Vandi to stay, or at least I think that guidance has been stay with Antora base functionality where we can, which makes sense. Yeah. Chris, go ahead. I think we may be possible that the feature, I think I asked us to next to the assertion might be possible. We need to investigate. Yeah, possible and worth the effort. Yeah. I mean, it should be if you've gotten different branches, you know, you know, a diff would give you the information, but. Yeah. Yeah, I think it's possible. And that'd be nice. I mean, it would be handy for Mark. To open up and look and see. You know, and then you could see that something has not changed for the last four LTS releases. And you know something about what's been in the releases and you're like, why is that not changed? Okay. Good. All right. Good suggestion. Anything else on that topic, Chris? Um, probably not. Much except for the fact that it still has exams. So we have to wait until he comes back maybe next week. Okay. So, so Vandits offline also this, this week. Great. That means I. All right. No problem. Very good. So. We continue then. I mean, it, it looks, it looks very attractive. Yeah. Yeah. What's your sense? Is it, is there. Any hope that it's going to be ready for merge at the end of the project, or more likely there's going to be a lot of work yet to do. I think, I think it might be possible. It depends on the schedule. Because I'm, I'm kind of worried like there might be some, like some other like integration. Issues that may crop up. Yeah. Yeah. Yeah. Got it. Okay. Great. Thank you. Thanks very much. Oh no, I had missed that we have build status. I need to remember that. That glossary entry is a good thing. Good. Okay. So we've talked about version documentation. Docker compose for tutorials. I was, I was hoping as your talk should show up. Well, so we did a demonstration last week. With us. For 45 minutes. Okay. And then I saw a demonstration. A five minute demo or a demo today from Bruno. And he'll do another demo. Bruno will, we'll do a more detailed demo. In office hours Europe. Next week. So it's, it's looking, it's looking quite good. I was, I was thoroughly impressed when we worked with it last week. Meg, what was your sense from being involved in that demo? I'll make may have slipped off. Okay. So I was, I was really very pleased. It's, it's now. I'm sorry. I muted myself because I was being noisy. I thought it was very, very nicely done. I was impressed. And the way he presented it, it was. Yeah, I just to give a, to give an indication. So I've got to show the thing that I just went through about 30 minutes ago to, to test drive. A change of version in one of our tutorials. So let's go look at this tutorial. Here's the Python tutorial. Right here. Click, click, click. So in this Python tutorial on my Linux thing, first thing I had to do is paste this command. Then paste this command. Then scroll down. And paste this content to a file. Then paste this command. And then. Paste this command. Okay. So you can see that there's this long horrible experience for the user. Copy and paste an awful lot of stuff. And keep track. So you don't skip something. Right. Don't skip. Don't miss a line, et cetera. And finally, after all that, you've reached the post install wizard. Well, what, what Bruno's. Has changed this whole terrible thing into three commands. Get clone. CD. Docker compose up. Oh. And it's that simple. And, and. Now inside the Docker compose. It's actually running. Two Docker containers. It creates a dedicated Jenkins agent. That's used for, with. The tool for the particular particular. Demo so in there for the particular tutorial. So in this case, because it's a Python tutorial. The agent has Python installed on it. The controller runs no jobs. So big win. Because this one, this demo. Actually relies on running jobs on the controller. Yeah. Do as we say, not as we do. Yeah. Right. Exactly. This. The Docker compose thing. Takes away some of the shame that we have hiding in this thing. Okay. So any, any questions there. I am, I am truly pleased with how it's going. And so I was impressed last week. Cause, cause Mark was playing with it. And he kind of tried to break it. He was trying to do some things. I think he was ready to explain to him. He's like, Oh, that works. So I thought the kid, the kid had shown that he, he's playing attention knows what he's doing. Yeah. Yeah. So it's, it's looking very good. Really. And, and it's a nice, nice improvement compared to what we've got. Okay. So, and it's not just, you know, when we say, oh, well, you know, it's installing Jenkins in the Docker environment can show that as well. Here's how you do it with Docker compose. Instead of this long horrible sequence. And by the way, the Docker compose thing converges Linux and Windows to use the same command. So instead of two entire sections. In the documentation on Mac OS and on Windows. You just on both of them say Docker compose up. Okay. Yeah. Nice. Yes. Any, any other questions or concerns on Docker compose? Nope. I've got one more Java 11. 17 here. I'll just copy it from earlier. I've got one more topic that I want to be sure we include here. And with the two of you here, it's a good one for us to be sure that we cover. Okay. Good. So. Docker compose next one is get lab plug in modernization. So here Mark has lots to test. Yeah. And I believe we're scheduled to meet meet in about, what is it about 12 hours? So, yeah. So I hope to have some testing to report then. We'll, we'll go forward and discuss there. And then the week after that, we'll go ahead and talk to you. Okay. Plug in health score. And so Jagruti seems to be, seems to be proceeding. There's some concern there. And they're discussing and seeing how, okay, what's next, how to help, et cetera. So. Moving forward. Good. Okay. Anything else on Google? Summer of code. Okay. Upcoming dates maybe, right? Yeah. It's for the final. Finally, valuation opens. August 28 closes September. Right. Yeah. Have we already done the midterm evaluations? Yeah. Midterm evaluation all four past. Okay. Oh, that probably why you are on vacation. That's why I didn't get updates and elsewhere. Yeah. Yeah, I don't remember. I, I definitely submitted my midterm evaluation. Okay. Chris, anything else on GSOG? Um, maybe the, also the final presentations. So, right, right. Yes. Yes. Yeah. Having them in mid September. I think. Yes, very good. Post evaluations. Okay. Anything else? No. Okay. Next topic then was open pull requests of interest. Here we've got some, some kind of cool news. So. Bruno Verachten. And I have checked that is in fact, how he pronounces his last name. Verachten, not Verachten. It's not German. It's French. Oh. And so Bruno Bruno has implemented. This feature that automatically updates that automatically submerged submits pull requests. Pull requests to update tool versions in the doctorate. Oh, so what we've got to look at is things like this. The one that I just tested. I've got to show you because this is really, this is such a nice capability because we were so erratic. On doing performing these types of updates. Yeah. Well, and, and you've got to track them, et cetera. So what Bruno submitted was a tool used to a tool actually authored by Olivier Vernault. So our free former infrastructure officer. And this tool. Let's submit pull requests to perform updates. And here's the one that I just merged. So the tool. Detected that we needed to change the Python version from 3. 10. 7. To 3. 11. 4. And it targets it on Alpine 3 18 and make sure this is a valid container. And I just ran through the entire tutorial using exactly this setup. And it worked great. Oh no, this is a fun one. This is a dramatically better setup. Okay. This one detected a. A badly outdated Python. So Python two. And. Correctly gave it a, a modern Python, a Python three version. Oh. That's cool. That, that actually is very cool. So. And this is the tutorial that I ex, that I, that I ran. And that tutorial works great. Very nice. So special thanks to Bruno for his work on, on a project. And thank you. Thank you. Very nice. So special thanks to Bruno for his work on, on update CLI, on using update CLI. We've got one open. Because we've, this one. Proposes to increment the node JS version, the node, the version of the node. But it proposes to change from using the long-term support release. To using their, their most recent release. And Damian to portal suggested, Hey, we should probably stay on this one with, with their LTS because. We don't do enough validation. And we certainly don't have automated tests that tell us if these tutorials still work. So choosing LTS for this one, when they have a concept of LTS is probably better. Although it might be good to find out if there's a reason for that. Well, and, and that's, that's a, that was, okay, you just voiced what, what my thought was, but I think the more I've considered Damian suggestion, the practical problem here is this thing could update every month. And if we don't test it, we have broken tutorials. Whereas if it stays on LTS, it updates every three or six months. And the odds of things being broken are much less. Right. But that, but okay, what actually what decides what version it's going to use of something. I mean, is that, is it doing that itself? It will somebody going in and saying, you know, this is what we should use for this. Yeah. So what I think what, what updates CLI will be taught is use something that has a base of 18. And then only increment the things after the 18. So if there were an 18.17, it would, it would choose it. But 19 or 20, it would not choose because those are not LTS's. So the, the initial configuration, at least that's how depend about works. You have, you tell it, I don't want things for to go any higher than this. Okay. Thank you. Then yeah, the one, I don't know, the one concern is once in a while, you get something where the LTS has a security problem. And there's a later release that's not LTS. It's just security feature fixes for that other one or something. Yeah. And if, if that occurred, then their LTS users have something that has a known vulnerability and that's, that would be rather uncommon. Yeah. I would expect just like Jenkins LTS when, whenever we patch a weekly for security fix, we also patch LTS. Okay. So that would be the 18 point something would be exactly 18.16.5 would be released if dot four had a, had a bug, had a security issue. Great. So I hate to disagree with Damien. So a very wise choice. That's good. He's, I like his ideas. So that, that looks really, really quite good actually. I'm, I'm truly thrilled. Next. Next topic on the poll requests of interest is this. Is this Kubernetes outline from Tannous Sharma? And right now there's been no additional, no additional progress on it. We've given our feedback and Tannous has, has not been back to it. So we've, there've been four or five commits that I did that Kevin Martens did of things we thought would help. But needs needs Tannous to come back before it. It, it gets more time. Yeah. Anything else on open poll requests of interest? Okay. So next piece and Chris, this one for you as, as in your role as release lead. I started a conversation with the release officer. With all the Jenkins officers and the board using this. Document as my oops. Using this document as my framework. So the concept here is that. Java 11 will reach end of public support in October of 2024. Right. So. So the first one, the version, the platform we use is October. Red Hat also October. Microsoft actually ends theirs in September of 2024, whereas Oracle will go all the way to October of 2026. If you pay them. And Amazon Coretto will go to 2027 and you don't have to pay them. So there's, there's a range. So we're based on Tamron. And so my proposal to the board and to. Tim Jacome and to Damian and to Kevin Martins was, let's declare that the Jenkins project will stop supporting Java 11. When Tamron stops supporting it. At the end of October 2024. And they were generally receptive to that. I said, yeah, that makes sense that follow that's consistent pattern. Then the next proposal was let's enable a Java 11 end of life admin monitor during October. So that of 2023. So that people who are running weekly have. A little over a year of warnings that hey, Java 11 will reach end of life for the Jenkins project. In October of 2024. So that would then mean it will appear in the December LTS. 2.426.1 or 27, whatever number it is. Any questions so far. Okay, so then the next piece of the story is. Okay, what do we do about upcoming releases? We've got Java 21 coming. In September of 2023. We've got about six weeks from now. Oracle and Eclipse and red hat and. Amazon Coretto and Microsoft will all deliver their builds of open JDK 21. And the, the, this end of support for them commonly goes as far as 2028. And potentially even beyond. So, Eclipse said, Hey, we'll support it till 2029. Red hat says six years 2029. So the proposal that I made was let's plan to release a Jenkins weekly version that supports Java 21 before the end of October 2023. And Basil Crow has agreed to do infrastructure work or not in to do core and tooling work if necessary. I mean, and the infra team have agreed to do the, the work on infrastructure and Kevin Martins has agreed to review and write documentation changes as needed. Any concerns from either of you on that plan. Sounds good. Okay. Then the next piece of the proposal was Java 17. Where here. We'll start active promotion, but we want to encourage people to go to Java 17 because Java, the Java 11 end of life admin monitor will appear in October. And we want to move people along. Okay. Now, if we look at the picture. Here's the picture of the current picture of JVMs. By Jenkins version. The green line that you see going up and then coming down is Java eight. And the green line that you see going up and continuing upward is Java 11 and this purple line here with now something like. 20 or 25,000 installations is Java 17. So even without the admin monitor, we're already getting adoption of Java 17, but our, we would like to dramatically improve this. And start tapering Java 11 off. Okay. So here's another question from, from Damian to portal. What about Java eight in our Jenkins infrastructure? Java eight is already not supported by Jenkins, but we keep it Java eight in the infrastructure because. Old plugins still need to use it to build. We don't want to break their build process. And what the status quote. Okay. Let's, let's maintain the status quo by continuing Java eight updates. Until Java reaches end of life, Java eight reaches end of life. In October, 2026. Open JDK will stop delivering versions. The other is if there were to come a time when Java eight updates became just too painful for the info team, they could tell us and we'd drop it then. So if this is just for tooling and just on Jenkins infrastructure, Jenkins still does not support job eight and will continue to not support Java eight. Okay. Yeah. Any concerns on any of those. Yeah. I mean, I'm wondering about. Any plugin that by. What two and a half years from now or something is still using Java eight. Yeah. Yeah. Yeah. Good question. So the plugin health score. Actually sees that already today. So if we were to look at the plugin health score. We can, we let's search for what should we search for? How about it? We'll search for plugins related to get. And here we see. A plugin called get parameter with a relatively lower health score. See if I can find one even worse. How about. Get hub organization folder. This is a good one because it's also a deprecated plugin. Okay. So we see here that on its score. It's got. What are some of its negatives? It's got. Oh yes. Here you go. Jenkins version. 1.642.3. That tells us. It's Java eight based. And so it's already being scored down. It's already having its plugin health score. Decreased because it's using Java eight. Yep. And then the other things that are diminishing its score here are part of the fact that it's, it's just not maintained. And this one is not maintained because it's deprecated. Okay. So if we were to look at its page on the plugin site. You see this big deprecated bar at the top. Yeah. So did that answer your question, Meg? Yes. Nice. Nice. Okay. So plugin. I'm thoroughly, I'm really thrilled with plugin health score. It is a very nice addition that Adrian has done for us. Yeah. If I don't look at anything other than the health score. But I see that, you know, those lower numbers, I might want to think twice as, you know, to have all this mealy mouth look and see if anybody's maintaining it. Right. Right. Exactly. And so what we've done is we've, he has codified. Checks to see those things that we used to say, please check to see if there's a maintainer. Please check to see if there are a bunch of bugs reported against it. Please check all those things. And when you, when you go to the health score, it will tell you these. Oh yeah, there's a reason it got a 44 out of a hundred. Yeah. So, or, or, okay, there's a reason why this one got a 98 out of a hundred. Right. And it shows you, hey, look, here are the positives. Here are the things that are aren't as good, but didn't diminish its score. Yeah. Good. Okay. Anything else on the Java story. Good work. Good work. Okay. Last topic on the agenda was DevOps world tour. I am pleased to announce that I am speaking. Mark is speaking in New York. And in Chicago. And what is Mark speaking about? The top topic that was approved is. Let's see how I got to remember the exact title. I just was, was creating the slides. So it should be right on my mind. So I'm going to talk about business benefits of open source contribution. And so I'm going to talk to people about why their business will do better if they will intentionally choose to contribute to open source. Oh, nice. Yeah, it's a, it's a fun sort of controversial really. You're telling me I can, I can improve my business by giving things away. And the answer is absolutely selectively giving things away can really improve your business. And I'll talk some, some reasons why, et cetera. I mean, it's a, it includes several stories from my life of highlighting, oh, here's why we did this. And it was specifically because it was benefiting the business. And here's why we did this. So it's. It's got some of Mark weight is old enough. Mark weight is experienced enough to remember some things. Okay. Any other topics for, oh, one, one last topic. I'm out the week of August 14th. Are you okay? If I just cancel this meeting the 18th, or do you want me to see if somebody else could, could run it? I'm good. I'm good. It's cancellation. Yeah. Okay. Consider the meeting. Not the same without you. Yeah. Anything else for today? Nope. Nope. We have some testing to do in the next 12 hours. Yeah. So I've got lots to do. All right. Thanks everybody. Take care. Thanks.