 Hello and welcome to the Jenkins documentation office hours. Today is January 18th and this is the EU US edition. Today around the table we have myself, Kevin Martin, Mark White, and Bernover Ockman. If anyone joins up, welcome in as always. For the agenda today, we've got the Jenkins contributor summit in Fostum in general. Contributor spotlight updates, the 2023 recap. This LTS to be published next week, GSOC 2024, version documentation for Jenkins.io updates, the sponsor adding sponsor page or sponsor attributions to the sponsors, a small update to the Twitter link in the footer, integrating the Docker compose into Jenkins tutorials, which great to have some movement on there. And the last thing I have on the agenda, if we get to it, we don't. If we don't, no big deal. But I want to start the discussion about having an upgrading Jenkins section in the documentation. So again, we'll discuss that when we get there, but until then, we'll start from the top. So first off, the Jenkins contributor summit, again, Fostum is approaching. We're just a couple of weeks away. So on February 2nd, the Friday before the Fosum conference, we're going to have a Jenkins contributor summit. And really exciting because most of the team is going to be there. We have four out of five board, we have four out of five board members and every, all the officers outside of Tim Jacome, we're not sure if they'll be able to get the funding for traveling there. But really exciting to have the full team there. We're going to have a great, we've got a really great plan for the contributor summit. John Mark Mason has been publishing a couple of blog posts, one as of yesterday about the contributor summit, giving a quick rundown of what we're looking at and details about where that's going to happen and what the plans are. And yeah, just really exciting times. I'm looking forward to meeting everyone and getting to share the documentation information with the rest of the Jenkins community. And yeah, really looking forward to everyone being there. Next up, so on the contributor spotlight, last week, we published Chris during spotlight. Thanks again to Chris for all of their work on the contributor spotlight and Jenkins in general. Uli Hafner's spotlight will be published next week. So we're ending the month strong and then we've got plenty to go after that. So once we get back from Fossum, we'll continue that publication. The 2023 Jenkins a year in review recap is still being compiled, compiled, but once we have all those entries put together, we'll get them submitted as a pull request and from there, it shouldn't need too much editing. So hopefully we'll be publishing that soon. LTS 2.426.3 is set to be released next Wednesday, the 24th. So the change log upgrade guide have been approved and merged already. The next baseline that we're looking at is right now the popular vote is 2.440. So that's looking really promising. We've got some great results from that and a lot of success there. So that's great news to hear. And then weekly 2.441 released this past Tuesday successfully. And then next week, we'll have 2.442 to be released as well. Next up on the agenda, Google Summer of Code 2024. So again, preparation has started. Chris Stern is the Google Summer of Code admin for Jenkins this year. So really excited to have them heading that up. We've got 10 mentors that have already volunteered. We can always get some more if there's interest there. We've got the call for mentors blog post. We've got the contributor session roundup online meetup. That's going to be happening on the 24th or the 25th at this point. I forget what the exact date is. Was it Bruno? Do you happen to remember what the exact date is for the contributor session roundup for some reason? I thought I think it's on the 25th of January. Because I think that was the I remember seeing the 25th. So that's that makes sense. Thank you. OK, perfect. Contributor session roundup. So that's for any interested contributors that are looking to participate in Google Summer of Code. That meeting's for you. Definitely attend if you want to contribute or if you want to be a mentor. Anyone can participate in that. And the great thing is we've been seeing a lot of Gitter activity for the Google Summer of Code Jenkins channel, which is fantastic. Chris has been responding to folks that are curious about it. I know others have as well. Bruno has been in there a lot of folks are just in here sharing their perspective and insights into Google Summer of Code, which is just fantastic to see. So I'm really happy to have that interest there and the community acting around it. For the version documentation for Jenkins.io, this is something that Chris Stern and Von D Singt have been working on. We've been discussing for some time. We know that January is a bit busy for Von D with exams. So what the goal is for right now is to do heavy review for the version documentation site. We've got the repository positioned in infra. The issue has been created in the infra for the infra team. Erve LaMira is helping with preparing that. And what I'm currently doing right now is going through and reviewing the various sections for a lot of navigation, link functionality, general site working or just making sure the site's in working order. I've been going through the installation docs and that's leading to other places as well. So the good news is I found some things that I can create issues with and provide that guidance to Chris and Von D so that they'll be able to take care of those things. So yeah, and like I said, with Von D being busy with exams the month of January, we're looking at February that they'll be able to come back and start working on some of these things with the full capacity that they wanted to be able to devote to it. Yeah, so I think it's great that Von D taken some time to worry about himself, take care of exams and then come back to this. That's great. And then, so Mark, I was wondering if you might have any insight about what's the policy for documentation versions. I think it was a note that came up in the Asia Docs office hours last week and I was wondering if there was anything more to that other than just starting that conversation. Yeah, so well, so I think the question was prompted by will we do 2.426.x as the version number and then 2.440 as the version number or will we do something different? And for me, the take was, I think we should do each LTS baseline. So 2.426.x or call it 2.426.1 and then 2.440.x and that way we've got, or maybe I should say it differently, maybe we can just admit 2.440.1 don't use the .x at all because it's a point in time snapshot and because it's a point in time snapshot, it should probably have an explicit version number that exactly matches a Jenkins version. Bruno, an opinion there. In fact, the Automat, everything guy in me prefers the 2.440.1 just because we could have a process of some sort, screwing, looking at the latest LTS version creation and then creating a PR so that we know that we can have another version of the documentation, something like that. So sorry to make it short, 2.0.0 something which is not x, just a number is good for me. So Kevin, I think that's a choice we get to make as the docs team and I think 2.426.1 is a good pattern. Let's do a quick check, open up git-scm.com, git-scm.com and in the documentation link that's there, reference manual, whoops, reference manual, pick any one of those, so config for instance, notice the drop down up at the top, so it's got 2.43.0 and it seems, yeah, so it seems they are doing it by exact version number. So now, I don't think we need to do. Dot two and dot three, I really don't think we do, it is enough that we get a version every three months, right, that's already much better than we've got. Yeah, right. I feel as though, unless something very drastic changes between that point one and the point two or point three that it wouldn't be necessary to even call it out at that point. Well, and certainly there are changes between dot one, dot two and dot three, but those changes are documented in the change log and in the upgrade guide and version documentation is about taking a snapshot of the entire set of documentation, basically it's a snapshot of a book. Yeah, and you two who have been working with LTS documentation for quite a long time, do you think it would be valuable to have a different version of documentation for dot two, dot three, dot four? I don't think so, I don't think there are that many changes in the documentation between the dot one and the dot three or dot four, or am I wrong? You're absolutely correct. If we made those kind of dramatic changes between dot one, dot two, dot three and dot four, it would be preceded by or accompanied by an entry in the upgrade guide and an entry in other places. This naming pattern doesn't prevent us from using adding a dot two or a dot three if something really motivated it, but I don't see the benefit. Why the pattern of users upgrading to latest versions of an LTS, for example, the two dot four, 26 dot one? Do people upgrade, do all people upgrade to the latest version when it gets out or do they keep with their first version and then there is a security issue, they then migrate to a newer version of that same LTS? Yeah, so let's let's let Kevin answer it for us with a picture and a picture that will, so Kevin, open up plugins.jankins.io, search for get client. So here's actually even better, let's go one better, search for structs, S-T-R-U-C-T-S, right? This is used in 98% of Jenkins instances. So it's a good sampling of total Jenkins instances. View detailed version information, Kevin, and now what you've gotta do is shrink this thing, keep shrinking because we actually don't need to read the numbers. Okay, now scroll to the right and all right, there we go. Now, if you'll scroll downward, what we see here, if you hover your text over the row that is over the rightmost column of the row that is the interesting LTS baseline. So LTS version, so scroll left to find what that is. So we want the one at the top of your screen. Let's look at 401.1. Oh, okay. Go all the way to the right now, hover over that 4990. So this says 47% of plugin installs are in this core version or newer. So 47% of all the installs of structs are on this. So of the 200 and almost 80,000, 100 and what is it? 140,000, 130,000 are already on 2.401 or newer. So now, Kevin, if you'll go down looking at 2.426. So look at .1 there and this one says one quarter have already upgraded. And now mind you, this data is only refreshed if I recall correctly, monthly. And so there's a delay period while people are upgrading. So this is a very conservative presentation of upgrade status. And we already see that half the users of this plugin are already on 2.401 and a quarter of them are already on the current baseline LTS. Okay. The question that motivated the question I just asked was would it make sense to have a global version for all the declination of the current LTS? Just one big version for the .1, .2, .3, .4 because they're on that many changes. So it would make sense to just squeeze everything together, right? Or not? I'm sorry, I don't think I made myself clear. Yeah. What things are you envisioning squeezing together? Are you thinking that there would be change between 426. documentation changes between 426.1 and 426.3 that are important? If ever that was something that happens, yes. Would it make sense to just keep the same version of the documentation and just modify it? And I think we have that option, right? By creating a tagged branch for 2.426.1, if we decided in some future day, whoa, there are enough changes in 2.426.3 to justify a new tag, a new placeholder on the version documentation, we could do that. Okay, because I don't know how the process works for the time being, but I'd like to be able to do it if ever it was needed. You know, I wouldn't like to be stuck with one version per LCS baseline and not being able to change it anyway. Well, and that's actually a good hint. Kevin, why don't you take us to the version documentation preview site? Sure. Because let's see what he's currently got. Actually, I think I might pull up, because I have it running on my local fork of it. I might just pull that up. Oh, okay, even better. Yeah, okay. You could look at the hot copy of the master branch. Yeah. Let me just make sure. Yeah, this is, okay. So this is, everyone can see the, this is the version documentation site. You can see here in the bottom corner, there's our options. Okay, and on the pick list for 2.426.x, what other choices are there? So there's user documentation, tutorial. Sorry, no, on the blue bar, sort of bluish bar, is there a down arrow, is there something on that down arrow that gives us a choice of something else? So there isn't right now. I think it's a way that it had been set up previously as it had multiple version numbers under the solution, like solutions page, for instance, and you could pick from which one was there. Like how the special interest groups or like how these have latest, but there would be 2.426 or 2.413 or what have you, as side from the 2.426. It looks like it's been removed in favor of working on latest. I don't know that for sure, but I know that there was previously multiple versions listed here underneath each header. Okay, so that's a piece where I think we've got, got to do some more exploring with Vandit site because I was assuming there would be a pick list here that somehow lets me choose whether I want 414 or 426. Yeah, me too. And obviously he chose 2.426.x, maybe showing my bad influence and I think it's easy for us to say, hey, .1 is probably the better choice. Yeah, and I think that's an easy enough change. And I agree that having the exact version is a little bit better for keeping everything aligned. But more so, I think it's, if it's supposed to be a snapshot of that LTS, that makes sense. And I think, like Bruno said, if something drastic or something were to happen between multiple versions, that would need to include that documentation. We can add that later. We can have a separate version specifically for that. So. Right. Yeah, and just for as far as Bruno's suggestion or question about having those versions, for the change log, from my experience, I haven't seen anything come through in the .2, .3 that's been so drastic that we've had to have an emergency or really necessitate a huge documentation change or any additions or anything like that. So it's definitely not common for that to come up. If it does, though, this absolutely gives us that flexibility, like Mark was saying. Yeah, agreed. Okay, let me get my stuff back. I just cleared my desktop. That's fine. Okay. So, yeah, so great. Thanks, Mark, very much for helping clarify that. And I think we have a great idea of moving forward what the next step would look like for there. Thank you. Thanks. Any other thoughts, comments, concerns about the version docs for now? Okay, great. So next up on the agenda, so adding the sponsor attributions, brief recap, our friends at JFrog asked about being attributed to the downloads. We said, yeah, we'd love to make sure that you're attributed to the downloads, but you probably do more than that. So let's make sure everyone's attributed properly as a sponsor. So thanks to some discussion with the governance board, Basil Crows, taken upon himself, he made a mock-up of the sponsors page that we can potentially add to the site. It looks really great. It's still in draft right now, but we've been having the discussion. It's been ongoing about how to set it up, what kind of levels we wanna put to it. We've got this Olympic medal idea that makes a lot of sense and frankly works for what we're looking at, with anchor being the highest level of sponsorship, mirror being something totally different from what that sponsorship, the regular sponsorship entails, and then gold, silver and bronze accordingly. Not everyone's contributions are measured monetarily, but this is something that makes more sense in terms of that impact that a sponsor has. So really great there. Still progress to be made. There's been some changes in the last month or so with different sponsorships and coming and going. So for instance, Red Hat is no longer part of the Continuous Delivery Foundation, so they're no longer a sponsor. They've been removed from the Jenkins homepage, in fact, due to that. So you can see they're no longer here. Oracle has not donated, or Oracle stopped donating as well. They're not mentioned there, so we didn't need to remove them, but still another thing to note. And Digital Oceans has been donated for both 2023 and 2024, and they should be visible there, but are not. So the sponsors page is a way for us to make sure that all of these sponsors are included without having to cram everything in one smaller space and give everyone the proper visual that they deserve, the proper opportunity to be seen. So it's a great, great endeavor, and yeah, more to come. Quick note, since we're already down here, we updated the Twitter down here in our community to be ex-formally Twitter, just to stay up to date with their branding as well. We had a discussion in the Advocacy Outreach meeting and decided it was time for a change. Thanks to Erve for including the little ex logo here as well, that's a nice touch that I wasn't sure that we could do. So that's great, but yeah. And then, so we've been talking about the Docker Compose being instituted or being integrated into the tutorials. So Bruno's taken it upon himself to do that and create that. So the Maven tutorial has got Docker Compose integrated into it and that hasn't been merged. So it's now live on the site, which is great. So we've got now in the Maven tutorial, we've got this Docker Compose instruction here. The idea is that we're making this a lot easier and a lot more accessible for people to set up and use. The Docker instructions are not necessarily the easiest and if something goes wrong, you have to then diagnose and figure out what that is. So the idea of Docker Compose is taking that aspect away, making it simpler, making it easier, making it a little bit more convenient to get started and get up and running. So again, thank you very much Bruno for taking on that work and doing that, contributing that and submitting that. The Python tutorial revamp is the same idea. I've been able to review that from a documentation standpoint. Just want to make sure that everything else is good to go there. And if there's anything that you need to touch up or update or fix or anything like that prior to merge that you have time to do that, if that gets merged prior to FOSTA and Grate, if not, it's okay, we'll figure that out. But everything looks great there too. We had discussed there was an interaction between, a specific interaction between Python and Alpine that Damian DePortel had mentioned, had brought up recently. We went through the tutorials and the documentation, Mark and I, and found that there weren't any instances where that's an issue. So the Python tutorial should be okay in that regard. There was some mention that it might not be up to date, but again, Mark did some looking through there, found that it should be more than fine and adequate. So everything should be okay there. So the long and short of it is the Python tutorial is also gonna get that Docker compose integration, which is great. Just need to make sure that it's, yeah, the final checks and reviews are ready to go. And then that's all passing, we'll get emerged. Any other notes or comments to share on the Docker compose stuff Bruno, or I know we've been talking about it for some time. So. No, you covered it all, thank you. But thanks Mark and thanks Kevin for taking the time to review it seriously. And the next tutorial should be about node this time. It shouldn't be groundbreaking, it follows the same pattern. Yeah. And yeah, that's okay if it's not groundbreaking. The idea is that we're getting better for everyone else by using Docker compose and incorporating it. So that, and that's like, and it's also the result of a Google Summer of Code 2023 project, which I think fantastic. And this along with the version doc site are just great examples of how GSOC is really beneficial to not only the participants, but the project itself. Everyone really wins in this. So it's great to have Google Summer of Code just on firing on all cylinders. So yeah, no, great. Thank you very much Bruno. I really appreciate it and thank you again for all the work. Thanks. Yeah. And so the last thing on the agenda, I think we'll keep it short just to start the topic and have this discussion and get going. But Vandeet actually submitted last year a pull request about adding an upgrading Jenkins section. It hasn't been touched a lot since because there's a lot of nuance and specifics when it comes to upgrading Jenkins. It's very dependent on the user's installation process, what their environment looks like and how it's set up, what kind of things they've gotten installed, et cetera, et cetera, et cetera. There are a lot of points where this could differ for everyone. So it's a great idea. Upgrading Jenkins as a section should absolutely exist and that instruction should be there. We just have to be very cognizant about how we approach it and how we're gonna include this documentation, keeping these sort of things in mind and what other aspects are maybe more important or more crucial to the process than something like that. If it's a matter of how they install Jenkins, what's the point in where we can have a unified set of instructions, for instance? Because with the installation docs, we have the various instructions for Docker, Windows, Mac OS, Linux, a bunch of other stuff, but at a certain point, they all turn into the same thing of unlocking Jenkins, logging in, setting up Jenkins itself. So maybe they're the point in the upgrading process that we can find where it kind of does that same thing, where these various points all converge into one. And then that would obviously make it a lot easier, but yeah, and there's probably nuances that I'm not even thinking of that could even come up after that point. So again, how do we consider those? How do we write this instruction so that it makes sense and covers those sort of bases? So again, we're running out of time for the meeting today, so I don't wanna necessarily get in a huge discussion. I wanna respect everyone's time, but it's something to consider. And I really appreciate Vendee's idea. He's got a lot of good work there to get started from. It's a wonderful starting point, but I think this is one of those things that comes with having just more and more and more and more experience with Jenkins, seeing how people are using it, being involved in the commute. Like there's more to it than a newer contributor might really get or have a concept for. So it's not the easiest thing. It's not the most difficult thing, but there are challenges working around the corner for all of it, so. Great. Yeah, I think this is something we can easily get done if a community can come together, though. Just gonna take some time and some discussion and figuring it out. So that's the end of the agenda that I had written up for us today. Is there anything else anyone wanted to just mention, discuss real quickly if they're out there? And if not, that's great. That will bring us to the end of our session today. Thank you, as always. The recording will be available 24 to 48 hours. And until next week, take care, stay safe, and we'll see you then. Bye. Thanks. Bye-bye.