 Welcome everyone. It's the 25th of August. This is documentation office hours Asia topics on my list. Google summer of code Choosing a plug-in bill of materials version add the existing requirements and support policy to a new chapter. I can show you a prototype of that and then veil.sh a command line for Making suggestions on text and DevOps world tour. Any other topics should like to be sure we discussed today. Interesting stuff. Go for it. Okay, so Chris Google summer of code, which, which are the topics are most of interest to you or which ones should we let ride for this session so we've certainly got tutorial improvements from Asher Tosh right and the project is the docker compose project. We've got the new site layout demonstration recorded in today's in UX SIG and in today's docs office hours Europe. Great. Okay, and then The others get lab plugin modernization that is not as directly directly related to documentation. And the fourth was or is why is it not registering for me. Me too. Plug in health. Oh plug in health score. That's right. And that one. So that one has been extended by about three weeks right. Yep. So as I am in this project and site layout is been extended about three weeks. Four weeks. Oh, it's four weeks. Okay, great. Now get lab plugin modernization. Harsh has recently is deep in back in school. So we definitely don't want to extend that one and Asher Tosh. I think the decision was not to extend either. Yeah. Good. All right. Anything that you want to share or any highlights for many of those. I think it's like we all work still working out the details for the gas being blocked for the new layout or alternative building to project so that that was like just like my idea is to have like the process automated and stuff like having to use them. The strappy because they were going to use like on on the canvas recommendation of gas be dodgers and also strappy as a back end for storing the data. But normally it's like that they have it's platform or portal for strappy. You have to use it's called it's kind of going to mean dashboard. But the thing is that I want to retain the current flow of like, processing blog posts. I'm not sure if that's sustainable. That's the consideration. I'm having. Okay, so, so is it that strappy doesn't provide a way to do reviews or what's the. It wouldn't be going through like the current like it would be very different from the way we're doing it now. Some people can do it like not everyone can do it. Okay, so it's, it's not publicly visible. We can make it publicly visible visible but it takes some work. Also like, so maybe for example, we can make everyone a reader that my way. But then like, not everyone can review it then maybe. That's the issue. So review comments are not allowed by readers they need to be a reviewer there's a different concept of reader and reviewer. And also it has to be done to be the portal or dashboard says it's kind of harder to have that way. We can we can make it work somehow to have the existing process. That would take some work to integrate like the whole setup with GitHub. Okay, so they've got they've got a front or they've got some form of front end integrated to their back end. That is not a GitHub pull request. Yep. Okay, all right. Interesting. Okay, but the, the, the, is that also for all non version documentation. No, just for blog posts. Okay. Non post. Non version documentation uses Gatsby directly. And get a pull request or how does some of them is like, in, I think, sometimes it's in and towards something in Gatsby. They should be they should there wouldn't be a part of the blog. I think hopefully we can set up so someone a block needs to be with our but maybe anything done with Gatsby to so I'm not sure if they figure out. Okay, version documentation uses and Torah and GitHub pull requests. Yep. And some non versions documentation to you. Yeah, right. Okay, good. So it's, if we set it this way, it would be and Torah for for GitHub pull request for all version documentation. Yep. And some non version documentation. Yep, that's correct. Okay, interesting. All right. Anything else you want to share there. And also, like, there's still a lot of work to to transition to the new workflow and new tooling. But we have to figure out the logistics to do so. Wow. Right. It's possible but we have to push it. Well, and we knew that there was a risk as we started this project that the new site layout was enormous. Right. So that's, that's not a shock. But the fact that we've got great demos and great concepts is already a victory. I think so, yeah. I think I did a quick job. Oh yeah, no question in my mind, just watching the layouts that he's been able to generate. Yes, it looks very nice. Good. I think it's still managed as in as separate branches or how are, how are the versions managed in his current prototype. I think it's the separate branches for now. Good. All right. Great. Anything else on the site layout. Okay, so I guess I can give you some status of what I know about the Docker compose project. It needs, it needs one or more new Docker new Docker repositories and Docker containers in those repositories. And the infra team can't take on can't do those Docker repositories currently, they just there. They've got too many urgent things that have got to happen instead. So we could do we could create a prototype. It uses Asher Tasha's or Bruno's personal repository personal containers for now. Not published to the Jenkins site we just keep we should not publish something to the Jenkins site that depends on a private repository that's that's a personal repository that's a mistake. Yeah. It would give us a chance to test drive the workflow test drive updating for new versions, etc. Yeah. Good. Okay. Any, any questions on the Docker compose project. Nope. Okay and on plug in health score unrelated to documentation likewise forget lab plug in modernization. No, no question about get that plug in modernization. Okay, go ahead. I've been asked like, how do you think about like at inviting harsh, maybe to be a co maintainer. Oh, that would be great is you think harsh is interested in being a coma co maintainer. I'm not asking, but I will invite him if it's okay with you, but I don't expect him to do much work while he is studying maybe maybe he can add like that more effort later on once he's like more have more time. Or once his education is over. Sounds good to me if, if I would love to have harsh, harsh remain somehow connected to the Jenkins project but I agree with you that education is his first priority it's most important that he finished that university education successfully but I fully supported if you'd like to continue to be involved. Yeah, so let me ask him. I was going to. Okay. Anything else on get my plug in modernization. Okay, so then I've got a question for you and for Meg. Let's look at I wanted to scribe an issue. And let's talk about how we would, how we would address it. Okay, so here's the issue. So this is from Kay Leonard. First name I think is, yes, Kyle, from Kyle Leonard. Kyle is a plug in maintainer so that's the persona we're dealing with Kyle likes to use the Jenkins plug in bill of materials. And the plug in bill of materials is a great choice because it allows you to avoid declaring explicitly which versions of plugins are in your dependency list. You said you just declare, I depend on this plug in and you rely on the plug in bill of materials this thing to provide the version number. So Chris I know you already know this this is mostly for makes benefit. All right so so that this is the thing that they insert this little block of text into their plugin palm file. Kyle correctly asked what's the value that I put here, the ellipsis there tells us, ah, it's not a known thing. I said well which one is it, and why would I choose that one. So here's here's the it's okay. What version and should I just go here and select the latest without caring about what version of Jenkins I put here, because this number 2.387.x is derived from a Jenkins LTS baseline. So it can be the 2.361 or 2.387 or 2.332 or 2.401 or 2.415 and and which version you choose there. Does that somehow have a relationship to this version number and the answer is yes it does. Okay so any questions on the setup to the to the problem statement. Nope. Nope. Okay, so now let's talk about about the the the situation so each each artifact ID this bomb dash Jenkins version number has a corresponding set of one or more releases of the of the build materials that are associated with it. But eventually we stop updating older versions and only update the newer versions and you can see that here. 346 the the newest version is 1763. That's when we stopped updating 346 for 361 the newest version is 2102 that's when we stopped updating that one. 375 the newest version is 2198 and the dot whatever. Now 387 and 401 the newest version. This is actually no longer the newest version, because this one is still being updated, and the newest version number is a larger number than that. Okay, question so far. I do have a question so at the time of the black of like this information is fast. So that is the latest version that was the latest version. When when I wrote this comment. Two weeks ago. At that moment in time this was the latest version. Now, however, if I instead look at the latest version let's go look at it just to show proof that, in fact, the latest version is 2357 not 2312. So there have been 45 changes since the point when I took this, I answered this question two weeks ago. And this number just keeps increasing on lines of the bill of materials that are actively being updated. Okay, no question so far. No. All right, so then now. Okay, now this is where it, it's a challenge right because we've got some lines where we can give the answer with confidence it will never change. This line if you if you chose 346. That's the correct version. No need to update it no need to revise it in any way. If you choose 361. This is the correct version it will never change because we've stopped updating that version. This one. It changes at least once a week, because we released a new version of the bill of materials pretty much once a week. So, my thought was, okay, we could and this was what I had put in the, we could put into the documentation of this repository into its read me. Here it talks about usage right. We could extend this thing by saying giving examples for each of those versions. 387. Here's a specific example. 341. Here's another specific example 346. And notice that I named these because they have certain significance right. This one is static, and it's the first Jenkins that requires job 11. This one static because it's the last to support job eight. Okay, so, so those three I could imagine but we've got two more now. 2.401. And 2.414. Yeah. And those are all actually tracked in a page that describes this process. Where is our, our page that describes the process let me show you that page. So it's called choosing a Jenkins version to build against. And here this is where Jesse Glick and Daniel Beck and others have helped us formulate guidelines to choose what should be your Jenkins baseline. And when you choose your Jenkins baseline that's the same version you should church choose for the bill of materials. So, and this page thankfully is automatically maintained. And notice that it says here 2.387.3 and 2.401.3 are good core dependencies, or you might consider 414.1. Now, those things two weeks ago said 2.401.3. And this one would have been 387.3 and this one would have been 375.4. And that would have been enough to be updated automatically. Now, how do we do the descriptions and where. All right, so my thought was the easy one is put them in the read me in this files read me and put specific examples with the option to write some update CLI code to automatically insert the version number here shortly after a release. And it would truly be as a plugin developer I just copy and paste this section and paste it into my code. No need to teach people anything just say copy this. It would yeah so because of because of the magic of update CLI there's a there's an action that gets assigned here just like we've got update CLI that's running already here. We could extend that definition and have it update submit pull request to update the read me. Okay, yeah, that sounds. For me that's a, that's an attractive option. I suspect the coding to do that may be more complicated, unless we do something like split split it out to a separate file swear. Okay, there's a file for three for the last. There's a separate version there's another file, and each of them is a different read me at the top level here, because there'd be a read me. Yeah, whatever. That way then update CLI only sees one version tag and only has to process one version tag that I need to talk to Bruno about he knows update CLI better much better than I do. I mean, is CLI is supposed to be a range of versions or just a single version single version. Okay. And real word I mean, what surprising me is that there's nothing here about which bomb my current plugin has been tested against. And that's a good point but that's actually right up here. So you choose you select the plugins LTS baseline. And, and that now this should probably be a link tells me choose the number I like. It doesn't say to your plugins LTS baseline should be a version that you have tested against and it's past or something like that. Well, and that's right. No, no, that you're not being pedantic at all but that is much more verbiage than needs than the expressing the concept you're trying to express needs to happen in this page. Okay, because this page describes the many different alternatives that might cause you to choose one Jenkins version or another as your minimum baseline so so this thing is giving you the what I call the engineering compromises between should I choose a newer version should I choose an older version. What's the impact if I choose a newer version what's the impact if I choose an older. Should I choose a weekly should I choose an LTS and why might I do that. And each of those is described here in this whole series of balancing between the competing priorities is all described here. So what if I have a version of the plugin that works on a set of somewhat current LTS releases, and then there's an LTS release that I do a different one for. And so, you know, like it's breaking so that the one that worked for, let's see, and minus two and minus three would not work for and current. Yeah, I want them both up there because both LTS is there still supported or all the LTS is there. Well, and so so the, the usual pattern there is a plug in a plug in starts with, where is that a plug in starts with, depending on an older version. 2.387.3 is a good example of an older version. This is, this is a relatively recent, as in within the last seven months, this was released, right. So this is, this is relatively recent, but not not brand not the newest. So, so it I'm using 2.387.3 that's my, my dependency I say you must have at least that it's the oldest that I will ever test with or support you on. Now, some change happens in Jenkins 2.414.1. And I decide I want to consume that change I want to be able to use that change then I will increment this version number to 2.414.1 and I then have to change this to 2.414.x. Is that what you were asking, Meg? Yeah, well, what if I still like in that in your example 2.387.3 is still out there and I still want my plug in to be available to people who are running that. It is because, because the previous version I shipped. So let's get very specific. I shipped get plug in 3.0 that requires 2.387.3. Okay. The new hot feature comes out in Jenkins 2.414. I absolutely want to use it. I could create get plug in 4.0 that requires 2.414. 3.0 is still available for users of the old line and I can actually continue releasing incrementals I could release 3.1. I could release 3.2 and we do that relatively frequently, especially in the context of security releases. So artifact ID and that that's why it's point X that will pick those up. Right, exactly. So this read me link to that other page about how it does not and that's that's one of the things already this phrase here, selecting your plugins LTS baseline, I think should point here. I agree. That makes for me that just that makes sense that it should. Otherwise it's like I like the number seven. Right, right. And so, so here I'm even going to do it while we're here because I think it's just as simple for us to do it while we're here as to. So the idea being that after selecting your plugins baseline like that. Okay, so commit the changes. And we're going to say, link to choosing a Jenkins version. Docs. All right, and we want a new branch. Prepare for more details. About version selection. From version selection. There we go. Okay. And new branch. So let's call this link to do. Version choosing chooser. Okay, got it. Link to choosing a Jenkins version. Start of improvements. Based on number. Number. Oops. Now we've got to see what the issue ID was. Oh, it's not that. Just a minute. Sorry, I have to make a good poll request. It's 2359. Okay. And make sure you're opening from a topic branch, which we are. Title represents describe what we did. Yes. Link to relevant issues. We did that. Link to relevant poll requests. Tests. And slash a. I think we're ready to submit it. Okay. Po request created. All right. So that when I think we've, we've got agreement makes sense. We just, we put that into the read me. Now. What do you think about? So here it says import the latest bomb from that line. And my thought was. Put sub put subheadings here. Three at least three different subheadings. One for this one. Current recommendation one for. First Java 11. And one for last Java eight. So does that seem reasonable to the two of you? Yeah. Okay. And I can do that separately. We don't need to do that during this session. Then. Then Joseph Peterson asked the question. Hey, shouldn't we also. Have something about choosing the bomb version in this page. And the more I thought about it, I thought probably not, but we ought to have a link from here. To the, to the bomb instructions. Then the question is which bomb instruction should we take them to. Because the precisely detailed bomb instructions are here in the, in the bomb read me. These are the most accurate, the most precise, the best engineering description. There's an alternative, which is here in the. In the tutorial for developers in the developer guide, improve a plugin. There's this thing with a video that talks about use the plugin bill of materials. But it is not nearly as detailed as, and in this case at the moment, it's actually wrong, right? It's this thing is manually maintained and needs to be upgraded from 2.375 to 2.387.3. And needs to have a new version number here. So the, the bill of materials repository is probably the better choice, not this tutorial. I would why not both. Okay. What I would say, you know, for, for the full explanation, go to the read me file. If this is your first time. If you're just getting started here and want a tutorial. Go here. Oh, okay. Good. Interesting. If they need, if they're a novice to this, they probably need the whole thing on using the plugin bill of materials. Anyhow. Right. Right. Good point. So, so they could get a, Hey, if you want a video overview, here's this thing that gives a video overview for, for details refer to the official documentation in the plugins, repository in the plugin in the bill of materials repository. Good. I like that. I mean, if there's a reason to have both documents, and I think there is, then they should both be referenced. The writer uses too many X rest probably, but. Okay. Very good. I like that. All right. So let me make a quick note of this one. Of that. So. Whoops. And risk. Stern. Both felt that we should. Should include a link. To the plugin bill of materials tutorial page. And to the. Documentation in this repository. My fat fingers and F10. This repository. In the page. So let's let me get. This one. And then. Okay. Good. Excellent. Thank you. All right. That, that was what I wanted to review. There any other comments that you want to provide before, before we go on to next topic. Nope. Nope. Okay. So next topic is we had talked last week or several weeks ago about the concept of adding the existing requirements and support policy documentation to a new chapter of the user handbook. So for reminder's sake, here's the user handbook. It looks like this. So it's got installing. Using managing. System admin scaling and troubleshooting. But in addition to all those things hiding under installing here. The Linux page has links to. Java requirements. Web browser compatibility. Windows support policy. Linux support policy serve the container. All useful things. But they're not in any place in the table of contents. So not easy to find. And. Not obvious to, to readers. Oh. This is an important part of, of your experience. So the idea that we had discussed several weeks ago was, let's put create a new chapter. And the, the where the prototype has put it is right after troubleshooting Jenkins called platform information. And what I wanted to do was show that to you so you can see how it's going. And we talked further about structure. You okay with that? Sure. Okay. So compile. Just a moment. So. Still building, still building, still building. Why is it after troubleshooting? That's a, that's a good question right now. It's after troubleshooting because that's where Kevin put it. Okay. No other reason. That is there's absolutely no other reason that it's after troubleshooting, except that's where it's been placed. We can suggest any place that we think makes sense. Okay. Okay. So let's go to the user guide and here we see already now there's platform information. Yeah. Okay. So, so first victory. Now let's jump into it a little deeper by going to various places. Let's go to any one of them and it stays there. So it travels up and down as we'd hope. So here's the platform information section. It's got two subsections, one called Java. And Java has three pages in it right now. Java requirements, Java eight to 11 Java 11 to 17. It will have a fourth upgrade Java from 17 to 21. Okay. So, so Java, but notice now we are two levels deep. In the nesting here. And, and it, it does expand and contract. And we've got, we've got at least one other place where we're doing that kind of thing. Sorry, what was that proxy configuration? Yes. Yes. Exactly. So we've got reverse proxy configuration that does in fact go a second level deep because each reverse proxy is sort of a sub set or a specialization of the more general purpose top level thing. Right. Yeah, exactly. They are effectively subsections. Yeah. Oh yeah. That's good. Chris's experience with the new, new thing. You know this very good. Okay. So, so the thought was with Java we've also got subsections. And now the navigation there is a little surprising for me in that it expanded both when I clicked on one of them. Oh, okay. And, and I haven't, I haven't investigated to see if that's, that would happen here as well because right or in the system admin page, because right now we've only got, I believe the only thing that has additional nesting in it is reverse proxy configuration on this. And it could be me, so I may be able to fix it, but can I take a look at the PR? There's not a PR yet. This was Kevin, Kevin handed to me said, Mark, this is completely broken. Why is it broken? And I was able to find one thing that fixed it enough to put, make this visible. So he's, he's not ready for a PR yet. He's still, he's still very early prototype. Okay. So when we get to PR, I'll certainly let you know, Chris. Yeah, because I think it's something I did because I was just not thinking about having to level to two folders. Maybe it depends like, because can we see the IDE for this? Is that just when we check something that when you say IDE, you mean, Oh, sure. Absolutely. Here. So, so it's in content. If I remember right, is it note docs? Hang on. I've got to go navigating now. Content. Doc. Book. Platform information. Okay. So here's the chapter definition for it. Okay. And then under Java. Here's the section. Yeah. And then if we go back here under support policy again, here's the section. Yeah. I think it's like something more, more like something else. When you change the code. I did it. I, I wasn't thinking about. Like. Where we get to the, like, no. Okay. Like, it was. Well, so, okay. So. I'm going to use this as my excuse to ask a different question. Then what if we attempted to flatten this. Into. A single list. Rather than Java and support policies. What if it was. Everything at the top level. Java requirements. Upgrading eight to 11, 11 to 17, 17 to 21 Linux support policies. And platform information only had things one level. One, one level down in it. What would the two of you think in terms of how does that feel structurally? It depends how many items there are. Is this the full list of items that there would be. This is almost the full list. So there are. Oh, I love your rule of seven. I bet that's where you're going. Isn't it? Yeah. Okay. So here are four items. Right. Those. There are four items. And those items. I don't expect to add many more to them because. This thing. It's very slow for us to add something to it. We added, we started with a windows support policy. Some years ago. I knuck. I caved and. Did the Linux support policy. We realized we needed browser and servlet content. We needed. And that's sort of reached the limit. And here, Java requirements, we get. General purpose Java and then upgrade for each transition. So eight to 11 is one. 11 to 17 is two. 17 to 21 is three. So we've got a total right now of eight. Leaf nodes in this. It would, it will grow in two years. To be nine because then we'll be going from 21 to 25. We still be keeping the eight to 11 at that point. I don't know if, if we would bother to keep eight to 11, because I hope by that time. We will have version documentation. And you can't do eight to 11. When you're upgrading from something that is. Only supports Java 17 or only supports Java 11. Right. And even like, I mean, eight doesn't bother me. If it became a list of 30, I think we've got a problem. Right. And, and I, I can't see it ever becoming a list of 30. But what I can see is, because I do like what you're saying. If it started to get too long, it could be a hybrid. But it could be a hybrid. If it started to get too long, it could be a hybrid. So we could have like Java upgrades. Right. Right. And under that have the different ones. That seems to be the thing that's going to. Right. There is, there is, there is certainly, there is an excuse that would say, Hey, we could do nesting. But as I look at Kevin's prototype here, I wonder, should we even bother with nesting? Let's, what if we just remove support policies and instead put these four items at the, at the immediate level below platform information? Uh huh. Yeah. Actually, I like it without the nest anymore. Because I can't defeat the perpetrator section. Yeah. Okay. Good. So, so that was, you, you sort of expressed my concern as well is the nesting here. Particularly when they, the two of them expand. At the same time, it, it doesn't do the information hiding. That I might have been hoping for. Right. So the current expanding contract behavior. I would have thought, oh, support policies. I only want to look at support policies, but it's expanding more than that. Right. And I could argue, I mean that actually the Java is Java support policies too. Right. Right. Right. It, this, the Java requirements could, could easily be rephrased as Java support policy. And then they're all support policies. And maybe it's, if we're looking to the future, then we say in a future day, it might be support policies and upgrades. But then, then again, if it's upgrade, I might want to, I might want to chapter upgrading Jenkins. Just like we've got a chapter installing Jenkins. Yeah. Okay. So I think what I'm hearing from the two of you is you'd be okay if this were flattened. Yes. Yep. Okay. Good. So I may propose back to him that we just go ahead and flatten it simply because it's, there's not so much information that we need to levels of nesting. Right. Great. And if it's some time it is, it starts to become unwieldy, we might nest one section of it or something. Right. Right. Well, and that would, that would be more and more akin to what this thing is doing where we've got one very special case, reverse proxy configuration. And it really is a very special case, right? These are specializations where you choose only one of them as a user. You don't pick, you don't say, Oh, I'm going to do two different reverse proxies. No, you choose one and you stick with that exact one. Right. But I may care about Linux and the browser. Right. Right. This, in terms of support policies, you probably have Linux and Windows. You certainly care about browser compatibility. So three of these items under support policies, plus Java requirements, you care about four of the five for sure. Now, servlets, we hope you'll, you just use the servlet we provide, but the other things really choosing a Linux version is a big deal. Choosing a Windows version is a big deal. Right. And the list that I see in the right frame, I like that order better than what's in the left frame. Oh, good. Okay. So Linux windows off very good, good point. So this is closer to my human interest priority. Human interest priorities. Servlet containers is the least likely for me to care. And, and the most variation occurs in which Linux version people are using. When I say if I see a list that has Linux and Windows isn't the next thing. I have a moment we're saying, oh, shit, they don't support Windows. Yeah. For me, it's usually the other way around. It's like Windows. There's no Linux there. It's like, yeah. But you know, but that because those, and if you did, if we did have to sub nest, I mean, there could come a time maybe we have, we pick up iOS or something, you know. Yeah, right. We couldn't get to a point where we had to make a subsection for operating systems God forbid, but it's possibility. Yeah, I guess, I guess I could see, I certainly Bruno Verochten for instance has done experiments trying to run Jenkins on Android as an opera and running it native on Android. Now that that experiments kind of a dark kind of experiment, right, because I'm not especially interested in running directly on that any more than I'm interested in running directly on other more exotic things like the system 390 VM system. But I see, but I see the future of these, you know, because I kind of don't do as much on my cell phone as lots of people do. I keep my computers and I do things on the cell phone. I think that's going to have to wait till I'm in front of a real computer. But people are doing everything on them. No. It could happen. It could. Yep. Good. All right. So I will plan to I'll propose back to Kevin that, hey, we discussed it and we thought maybe flattening it would be the right choice given the content. And also I have something to raise. So it seems like we are like migrating to the tuition building website. So like maybe by the time we need to upgrade. If we're using a toy, it's a lot easier. Oh, good point. Okay. And I also found the culprit for the code like why he's not working. Because I just on the chat. Yeah. All right. Thank you, Chris. So, so is it worth fixing it so that this could expand and contract if we need it or is it just not worth the bother? Maybe not now. Okay. Good. There's, we, we don't need it as far as I can tell, because I think this should just be a single, a single depth list. Okay. Yeah. A list of depth one. There we go. All right. And I also think it should be up. Like I would put it after installing it actually. Oh, good point. Yeah. So let's, let's get. So the idea here was put it installing Jenkins platform information up there at the top rather than putting it down. That's something I can do as well. Good. All right. Anything else on this particular idea? No, nice work. Okay. Good. All right. Let's see. So, given that my level of exhaustion at the moment, I propose that we call it done for today. There is an interesting tool to just mention in past passing called veil.sh. That is a, an open source command line tool that's willing to make comments on your editorial style. Wow. Gavin Mogan said he's using it. And I don't know what, what his experience has been, but it offers suggestions and. So. What's he using it as a style guide then? Is he using Google? No, it hasn't built into its own thing. So I don't know what it's editorial style guide, but it's fast and dependency free, meaning it doesn't look at anybody else's thing. So I'm not what they're using for their style guide. Oh, I'm sure it's very, well, yeah, here we go. Absolutely. I'm going to try to avoid using first person plural like we. Yeah. Okay. So feel free to use we've instead of we have. Avoid using will. So it's, well, what is the right? It looks like, so. Google that parents Google that will Google that we. So that looks like he's using some from the Google style guide. Well, and that's since it says it's extensible. I suspect these are probably extensions, right? Google has a style guide veil has their own style guide and. And there are people obviously contributing. Things to the style. Right. It seemed from what I know, and I am not a style guide expert, except I've become extraordinarily good at avoiding exercises and creating a new style guide. I've done that just enough to. They don't want to do it again. But there's a lot of people who seem to believe in. That it's the Microsoft style guide that was handled down at my. Mount Sinai. I kind of like the Google better. Oh, I am the wrong. That those are the two, those are out there. Yeah. And I, I'm unfortunately. Largely oblivious to style guides at that level. So. Right. But there, because a lot of, I mean, a lot of it is just good sense. The big one that I look for is. Heter capitalization. Okay. One. I don't care to ever participate in another discussion. I have sort of what I prefer. I can live with any of it. Whoever feels strongest, you win. I'm done. Right. But. But what I do hate and I do this all the time is create a document that has a mix. But because we, I'm not working under a style guide that specifies it. So. Some days I do one thing. Some days I do another thing someday. I'm reviewing somebody's text and I make them change it. Other days, I say, I have to let it go. Right. Okay. All right. That's all that I had. I have to forewarned there will be some times in September and October where I'm unavailable. Because I'm a speaker at DevOps world tour in New York, Chicago and Santa Clara. Oh, yeah. And if you're in the Santa Clara area sometime, Meg, I may send ping you and say, Hey, I'm in town. I was going to say, I would love to see you. That would be fun. I agree. But not enough to come to DevOps world. I might add. Okay. I detected a hint of rebellion there. But okay, that's great. No, I just, I, I do not enjoy big conferences, even when I, you know, when I need to be at them. Sometimes I have fun, but I don't love them. So. But we can, there's lots of places we can get together. Abulus. All right. That's all that I had for today. Thanks very much. Recording will be available in about 24 hours. Terrific. Before you hang up, I have a very quick question for you. Yes, please. What version of Ubuntu do you favor right now? Right now I'm running 2204. Okay. That's what I was going to do. And then I saw there was 2304 and then everybody's excited about 2310. And I'm like, why would I go to 2.10 unless 0.04 is messy? Which made me think 22 sounds like a nice even number. Well, so, so I'd worry it depends on depends on how often you're willing to upgrade. So 22.10 has a, I think a six month life cycle. Or maybe it's a 12 month life cycle and 2204 has a 10 year life cycle. Wow. And so, so it's. Well, I'm installing a new computer to replace one that's running 18. Does that answer your question? So then you, if you, if, if you're replacing an 18 installation, then your pattern of behavior lobbies you've seen installed 2204. Okay. I got to say with something real, I mean, it wouldn't, and I'm, I'm vowing that I'm going to upgrade more frequently, but. Right. Yeah. So, so your other all your other choices are to go for 23. I would avoid 23.10 absolutely because it upgrades more frequently than you're willing to upgrade. And 23.04 does not have the 10 year life cycle that 22.04 does. Oh, okay. So that only their even numbered releases get that long life cycle. Okay. Okay. Good to know that I was trying to, I was going to go do the research and I thought, Mark will just know that would be so easy. Very, very good. Yeah. I'm actually, Mark's got some really hot topics about this thing. Java 1117 and 21 discussion that. Yeah, we've got some very interesting conversations about the next three to four years. How they will look for Java support in Jenkins. So, yeah. And then final question, did you have a wonderful time on your vacation? I did. Although I ran over my, my own foot with an all terrain vehicle. And so my foot swelled a little bit and no broken bones, but I'm limping a little bit. So Chris, I'm not sure if you recognize the term all terrain vehicle, but ATV is a four wheel, like a motorcycle with four tires instead of two tires. We were out in the dirt in the mountains and it leaned a little to the left and I'm a bicycle rider. So I put my foot out and then drove over it. Oh, Mark, I'm so sorry that I'm glad you didn't break anything. No, no break. And you know, just, just laugh and the doctors. I laughed at the doctor and said, doctor, your diagnosis should be stupid in all capital letters. Right. Because there's no excuse for it. My brother who was with me said, this is not a bicycle. Don't put anything outside of the vehicle. Oh dear. All right. Thank you everybody. Have a great night. Thank you. Take care. We'll talk to you next week then. Bye bye.