 Hello, and welcome to the Jenkins documentation office hours. Today is September 9th, September 7th, sorry. That's my American showing. I can't read things properly, but is September 7th. This is the EU U.S. edition and today we have myself and Bruno Vrockman joining. Mark is unavailable to join it today. So if Chris Stern or anyone else has time to show up, we'll welcome them in. Other than that, we'll go over the agenda. So for the agenda today, we have several blog posts that were published in the last two weeks, roughly a couple beyond that, but still related to others. So they're listed there. The Google center of code is Getting to the end of its project, which is really exciting. A lot of the projects have that made great strides and are close to complete, if not already completed. So we'll talk about that. The process of choosing a plugin and build materials version, the Java 11, 17, and 21 support proposal for Jenkins. This is something that Mark's been working on and other developments have happened with Mark not here. We might not have his nice planning schedule proposal, but even still that's something that we've been discussing. This is something that I noticed has been in the open pull requests that Bruno actually really saw because I saw your recent comment on it about users suggesting what about using W get instead of curl. Oh, yeah, we'll talk about that a little bit. I think it's just a good topic to talk about here in the office hours. The Jenkins doc contribute a project. This is something that hasn't necessarily been brought up here in documentation hours previously, but we're actually getting to the point of being ready to or gearing up to publish and make things live in the coming weeks. So I do want to talk about that and also see if there might be anyone that can help out with some of the HTML generation. And then last up on the agenda for today, I have DevOps world tour that's starting next week and we're going to have Jenkins after hours sessions. I forget exactly what Mark called them earlier, but Once the DevOps world tour day is complete, or if it's two days like next week in New York, we're going to have Jenkins discussion time after hours meeting social hour. I don't know what we're talking about. I think for time being it's called let's talk about Jenkins. That's perfect. So after DevOps world tour is over, we have let's talk about Jenkins. Thank you, Bruno. You're welcome. Is there anything else that you feel needs to go on the agenda or you want to discuss today? No, I think we're good. I just have found the URL of Mark's proposal for GTK 1117 and 21. Oh, beautiful. So I put the link in the document. Awesome. Thank you so much. You're welcome. Okay. So first up. So, so we've had several blog posts published recently. The risk five blog posts for Bruno and Dr. Compose and GitLab plugin from Parche and Ash Tosh respectively were published just prior to the two week. But yeah, like I said, we're including them because they have to do with Google Summer Code. And they are recapping their project work, which is great to see. They're sharing their insights, their challenges, their successes, everything from their projects, which is really nice to see. It's just great work all around from the Google Summer Code participants for their consistent work and dedication to getting these things taken care of. And then the risk five blog post that Bruno had written is really nice. It paints a great picture of what the future can look like for Jenkins, including Java support, Risk Five, Arch64, Arm64. Just kind of like all the different developmental options that Jenkins could have going forward. And thank you. Yeah, of course. Is there anything that you'd like to point out, call out, or? No. I think it's the first post about JDK 21. And we'll see lots of more posts by people who know what they are talking about. For example, Mark Wait about JDK 21 because I'm all, when it comes to experimenting, I love what I'm doing. But I'm not the one who worked the most on JDK 21 for Jenkins. Not at all. It was fun to experiment with JDK 21 and Risk Five at the same time. And yeah, you will see more articles about JDK 21 and we'll talk about that maybe later in the meeting. No worries about the image. No copyright or whatever. It has been generated with AI, of course. But which doesn't mean that the AI hasn't ingested things that were proprietary first. I honestly didn't even, I didn't notice the Jenkins logo on the hood of the car the first time. So I actually just noticed it and that's why it's up here. I really, that's just funny and I like it. Yeah. And there are also Jenkins written on the front part on the grill, you know, Jenkins. Oh yeah, look at that. And this one was not AI generated. Same for the hood. It's just my poor skills on Photoshop. Anyhow. Could have fooled me, no worries. I like it. We'll talk about my headshots next time. But yeah, so fantastic. Thank you so much, Bruno, for that and a bit of insight. And then the last two blog posts we have listed here. So Mark just wrote this yesterday. It's just a brief, brief, brief preview of what DevOps World 2023 will look like for the Jenkins project. So introductions to Tim Jacome, Olivia Alami and Mark Wait. What their backgrounds are, what their marks is goes into a little bit about what he's going to be talking about. But yeah, just a quick little preview for those attending or those wanting to attend. And then this was just published yesterday as well later in the day. But this is part of the Artifactory bandwidth reduction project that has been going on for some time now. Just some updates regarding Maven central caching and kind of what we're learning with the respective downtimes that have been going on. This is helping us figure out what is causing bandwidth overuse. We did have some, we've had issues recently with overuse by some users. We've managed to nip some of that in the bud, but not all of it. So this is still the ongoing process of how can we make the usage a little bit less, well, huge, I guess is the best way to put it. Jay frog would love for us to get down a little bit further than we're at now. So that's the that's the goal of the project. That's what we're working on. Anything else on the blog posts? No, thank you. Okay, I was making sure. Great. So then next up Google summer code. So as I had mentioned earlier, Google summer code is getting towards the back end of things at this point. I know that we still have a few weeks and that the participants are going to be creating their recap blog posts to do a full just kind of retrospective on their project and what they worked on and everything. That's what we use and have used in the past for Google as one of the one of the project completion points for Google is having a full summary of participants project and the work they did. So the blog posts that will be coming out and then have been published are those those recaps. So there should be a few more coming, but that's only that's the and that's due to the fact that Djigrude has submitted a few different blog posts regarding the different probes that she had worked on. But that's their smaller individual blog posts for each probe as opposed to a full recap blog post so little things. But as far as the projects go, so the doc compose has been successfully completed four out of five tutorials are now executing with a single command. And there is some remaining work to take on, but the projects that that's been completed. So this is all, you know, after the fact this is in addition to not something that we needed to do to get past the finish line. So that's fantastic. The next. So then we've got the version documentation for building Jenkins I owe that body and been working on the demo site has been really great to see Vandy and crystal have been demoing this respectively at various meetings over the last couple weeks for the Jenkins project and the Jenkins community, which is great to see. And they're getting to the point where they're it's they're almost out of working site just amazing. That's been integration needs some work and they just abandoned the strap strappy backend idea, which was specifically for blog post reviews. And then, yeah, so we're going to continue to use GitHub for blog post reviews, no surprises there. There are still some links that need to be fixed and updated to make sure that they're pointing and directing properly. But that's something that they're working on. And we'll just take care of as we go along. That could even be potentially something for October past if that's necessary. But we'll see how much access or knowledge you need for that. Next under the Google summer code. So the GitLab plugin modernization project has completed successfully as well, which is great. Harsh has actually agreed to continue as a plug in maintainer. And that's a first time a contributor became a maintainer for Google summer code. So that is amazing in and of itself. Just thank you, Harsh, for the work and for stepping up to maintain the plug in as well. That's amazing. And that's really heartening to see from the Google summer code. It does still need some more testing, but it's completed. And, you know, that's the main point here. Everything will need some work and maintenance after the fact. That's just how things go. So knowing that, but having it completed and ready to go and have Harsh's enthusiasm and dedication to that is, yeah, like I said, really heartening. And then finally, the plug in health scores. Yeah, there have been a couple of probes. There have been several probes that have been looked to be completed and merged. There might be one other one that I'm forgetting about right now. But everything looks to be going well here. Yeah, this, this is actually the project documentation might need additional documentation here for the plug in health score. And that could be something that we do for Hacktoberfest. Adrienne would still be available and could guide or potentially help with that. But if we do a Hacktoberfest, that gives the opportunity for anyone else to come in and help out. So, yeah, we'll get opportunity there. Anything else on Google Summer Code projects for now that you want to mention or highlight? Not really. In fact, we're almost good. As you told earlier, Ashutosh has passed years finished the Google Summer Code, except that we still have to, you know, create some pull requests on Jenkins IO because we want to modify the existing documentation. And there has been no progress on this area yet. The thing is, we can't change the documentation and point to Ashutosh on Docker Hub Registry. So, yeah. So, they will come when they will come. Okay, great. Good to know. Thank you very much. Next on the agenda. So, this is something that we've been discussing in the last handful of weeks is how to describe our project. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, yeah. So, this is something that we've been discussing in the last handful of weeks is how to describe the process of choosing a plugin bill of materials version. So, this is a result of a discussion being started in this PR that Kyle had submitted. So, basically saying that the instructions are a little unclear or not explicit when saying which bomb version to choose based on the Jenkins version itself. There are a couple of different pages to go to to get the releases. So, for instance, there's our GitHub release page where you can scroll through and see. You can also search here. But the other end of that is. Yeah, this one just lists them out here very directly straightforward. And Kyle is saying this is this is just easier to kind of navigate because it's more clear and direct in that sense. And then Mark responded saying like hey like what if we do something where we have that bomb version and we explain like what this is for or like the specific use case you would want this for such as having 2.361.x be the first one to require job 11 or 3.46 being the last Jenkins to support job 8. So, yeah, that would help. This week as I was trying to help a user who was having some trouble with the palm plugin. I say, oh, you know what I try my luck. I will try to update the palm plugin just in case, you know, because he was trying to use it on bookworm and it used to work on db on 11 but it doesn't work. It's working more on db on 12. Anyway, so I said, hey, why not try to use the improve a plugin tutorial while I'm there so that the plugin will be more updated with good practices. And in one part of the document, there is bomb that you have, you know, I think it's done with update here I whatever it's bomb 2.387. Okay, why should I choose this one? I have no idea how is it linked to the version, the minimal version of Jenkins I'm supposed to use. I have no idea either. And then later on in the tutorial, another step uses a bomb with 2.375 something. Why this one? Yeah, that if I ID, yeah, why so definitely we need something better. Yeah, definitely. I think Mark had mentioned even using the update CLI to do that sort of thing. If I'm not mistaken, that was an option that he had. Yeah, that could be an option that we use the future and I think he actually with Asia Docs office hours I think they determined where they could add in this. This, this exact sort of guidance and if we go to the bomb repo in the default read me here. Yeah, I think this is the one. Yeah, this is the one that Mark went to now and read me for the bomb repo. So there has been some update, but yeah, it's not nothing that has been enough to move this original PR. Yeah, maybe we need to discuss it a little bit more before doing the change, but yeah, it's cool that we have this discussion on the community. Yeah, exactly. This is kind of thing that is really useful, not only for like this instance, but going forward to other instances or if this comes up again in the future, maybe we can take what we learned here and even improve further. It's one of those just kind of like universal gives us a good way to figure out what the best course of actions. The next thing on the agenda is the Java 11 Java 17 and Java 21 support proposal that Mark's been working on. So the long and short of it is Java 11 is currently supported as well as Java 17 and Java 21 is going to be supported in Jenkins as well. We've been working on testing with Java 21. So this has been happening and it's happening a lot faster than originally anticipated. So the odds of Jenkins supporting Java 21 after its release this month, very, very, very highly likely. If not, it's going to happen. So I did ultimately, the idea is we want to get on a cadence or a kind of routine where we are able to update according to the Java update flow. Because it's very much a work in progress. There's still a lot that needs to be done here. But yeah, the idea is that we have a plan in place to drop Java 11 support eventually include Java 17 support potentially require Java 17 and then supporting Java 21 and when we can when we might start requiring Java 21. And even then that's been a bit of a discussion. Some developers feel that maybe just skipping Java 17 requirement and just requiring Java 21 could be beneficial. It does provide, you know, got much more power functionality tooling testing, etc, etc, etc. But that is. Yeah, that's that's a little further away from the rest of this right now. Is there anything else that you wanted to share about the or any insights you have on that one, Bruno? No, I don't have that many, but I think the goal is to have Jenkins support each LTS version of Java for four years. Java will be supporting their LTS for six years, but I think we will get rid of the two last years and move to the next LTS version. I think that's the goal today. But as you say, there are still lots of discussion to be had. Yeah, we have to discuss that more and more and more. But hopefully Jenkins will be able to support JDK 21 by the end of October. Yeah, and yeah, that's the goal. I'm actually running through the documentation right now to make sure things work like the tutorials, just when Java 21 is in play like that. So far, so good. So everything seems to be going pretty smoothly on that part, which is nice. Java 21 seems to be proving pretty useful in a lot of test cases and experimentation that's been going on. So that part, at the very least, is encouraging to see. And yeah, lots more to come on that. This pull request, I just wanted to bring up and have a short discussion about it. So the reason being is this user brought up that the way that they've gone ahead and installed and set up their Jenkins not using Perl, their default or their their main action was using W get. And so this is all very dependent on how you're setting up your own operating system, your own Jenkins instance. So it's not consistently an issue or something that's hard and fast tied to a specific usage. This person, they just happen to have W get as their like default in this case, let's say. Yeah, so it looks like it's default on Ubuntu, but I've never ever met an instance of Ubuntu, Debian, whatever, without curl. I think it's one of the first things I install. But yeah, I can get it. Some people get a fresh installation of human to with nothing, no additional package install and then they try to install Jenkins and it fails. But as I wrote, I'm in the middle of the bridge. I don't know if that's it's US idea. Maybe I was trying to translate something French that doesn't make sense in English, but whatever. I don't know. Each of the two proposition makes sense to me. You can keep curl and say, oh, it's a prerequisite by the way, or okay, we could switch to using double you get as each and every destroyer is supposed to have it. I don't know what's your feedback about that. So I was I was thinking. I was looking at it and I was looking at your response Bruno and I was thinking that either some kind of disclaimer potentially at the top of a page at some of the on the top of some of these pages or potentially if there's a specific section that seems to be a worse offender than others maybe. But yeah, I would say the disclaimer in my head instead of saying something like you should have curl installed is something like if you don't have curl installed use, you know, this is what that's where you would put your action item or like, and if if you're not using curl replace curl with W get or something like that. Yeah. I don't know. I recognize my phrasing is not ideal. That's not what you meant, but yeah, we could do something better. Yeah, I guess what I'm saying is like, even if even if we don't encourage them to install or use or like install something specific or use something specific. If we just trust that they know what they're doing. Trust in the reader is sometimes tough because you want to give them as much help obviously without, you know, making it too dumb down at the same time but I feel like there might be something we could do where we don't necessarily replace because I don't want to replace curl with W get throughout the documentation. I think curl is and like you said, pretty universally used and installed on default. But yeah, just something small to say hey if if you don't have this use this or something like that. But that would also that requires the user to know what they have installed and what they're using and yeah, it could it could be tough. I think it just but it really boils down to the user who's performing these actions and their knowledge of their environment. Yeah. I forgot the name of what I want to talk about but do you think we could have an expandable section, you know, just in case if you don't have curl and then they click and something appeals with W get command instead of curl. Or do we have a little things a shadow thing or yeah like like an example drop down or like that you could that would be collapsed but could be expanded and then if yep and it says if you don't have curl use this thing. I like that too. Yeah, that's I mean and that's the kind of thing that I was thinking because I don't want to put a disclaimer at the top of every page or like at you know at all the install pages or something. Something like that might be a better option, especially because we could put it just in front of code blocks, where this would come up instead of whole page so yeah, yeah, I like that idea. It's a little more elegant, but yeah, but I thanks for discussing that with me ever know I think it was like I said a great example of where there could be questions or challenges to the documentation but we have to. It's not like an easy decision it's something that we definitely need to talk about as a community and a project. So I noticed we're at time. I will do the DevOps world tour info really quickly. I would like to take a minute just to talk about the computer project if that's okay with you Bruno. Yeah, yeah, go ahead. Thank you. Yeah. So DevOps world tour starts next week. Again, we're going to be touching multiple locations multiple countries across the world. New York, Chicago and Santa Clara, California are going to be our US stops mark wait will be attending all of those and we'll be giving a talk as well. And then after the end of all of these DevOps world tour sessions we're going to have Jenkins let's talk about Jenkins time. So once the conference is over, we'll have separate, separate session where we'll be able to talk all things Jenkins. Mark will be at the California the US ones, Olivia Lamy and Ginger Khan will be at the Singapore and London ones respectively, and they'll be getting their own talks there as well. Again, the preview page blog post went up today so it is there for further information and the DevOps world tour site is still available for registration, if you haven't already got. And last thing on the agenda so brief summary, we've been working on this for some for some time now. We want to recognize and acknowledge and spotlight highlight and show appreciation for the top contributors to the Jenkins project. This is an open source project that would not be where it is if it were not for the contributions and the dedication and hard work of the community and the contributors that continue to prop Jenkins up as it is today. So we are working on getting a compilation of contributor stories. Each of the top contributors has been will be responding to a questionnaire sent out or doing an interview with me, where we can capture their stories or experiences, etc, etc. And then we're going to be publishing these live on either the Jenkins.io site or stories. But basically, we just want to show and spotlight the various contributors to Jenkins and give them their moment in the sun that they deserve for all this. We've gotten to the point now where we're getting responses back. And our next step is to create a landing page slash overview page for the contributors and the individual contributor pages themselves. Just to shout out Christina piece of gaily who put this mock up together just amazing and just really wonderful to work with thank you so much Christina for doing this. This is just the really nice little landing page that we discussed simple. We'll have a different 25 is not hard and fast that's not going to be a part of that text there but that'll be changed. We have the contributors. And then we'll have the individual contributor page like this where we'll have their interview posted links location. This is also to show just how global the reach of the Jenkins project is and get people connected get people some background to the folks that they might work with and never really get to chance to talk to. That looks cool. Yeah, really excited and yeah Christina did amazing with this just coming up with a mock up. Alyssa and I met with her this past Tuesday and she was able to get this put together in a couple days. So yeah just once again massive thanks to her and appreciate the ability to be open to this and helping us out with this. So if anyone has any sort of HTML skills and would be interested in helping put this together HTML is not my forte unfortunately am not a developer. So if anyone has any HTML skills they want to flex share and maybe even show me how to do some things more than happy to take a look. I have posted in the UX Gitter channel as well. So it is there too but yeah if anyone has any insights or would like to assist in building that site. Just let me know. I don't unfortunately you know contributor recognition and appreciation is a massive subject for open source communities. I'm part of something called community maintainers on GitHub. It's a special repo where people discuss about their open source community and lately there has been a subject called contributor recognition and appreciation and all the people participating are facing the same issue as we have. How should we put people under the light and frankly there is no answer. Everybody does things more or less looking the same and they're not happy with that. No magical skills or one or whatever that can help. Lots of people have thought of technical solutions to this for example you know finding all the contributors in their GitHub repose and then crafting automatically page which lists all the contributors with their avatars or whatever. But most of the time it almost works but it does not work. There are lots of manual integration things to modify by hand afterwards because they also want to link that to people as LinkedIn account for example Twitter account whatever and you have to do that by hand because people may be called as me put down on the platform. On another one and so it doesn't match so the technical solution is not there. I think we may gather some statistics whatever but there will be some things to do by real human. I'm afraid it's that it's funny that you mentioned that because when we were discussing different ways to highlight and appreciate that one of the things that I had thought of was one of those contributor kind of bought display tables. Yeah that's about to is called all contributors bought. Yeah okay of course. Yeah that's the one I was looking at and then when I was trying to set it up in my own repo to test it out. Those are the exact things I found out myself to how it's a lot more work and involved than it feels like it should. Yeah it looks like a good idea until you try to work with it. Yeah but yeah it's good to know that that other people are having kind of facing the same thing. It's definitely a hot topic and in my own research and trying to figure out how we can do this appreciation. I mean it's tough with open source projects not being for profit necessarily takes like it's hard to do recognition in a form in a forum where there is not necessarily a monetary value associated with that appreciation or like that hard work that you're putting in. And it's like it takes passion it takes dedication it takes a lot of things that unfortunately do not always get valued in how we would maybe like them to. But yeah there's yeah sorry. Oh no I was going to say there's it remembers me of the things I used to say to my kids when they were younger you know they were waiting for a reward when they were getting good marks. You know I plus or something I should get something you know a candy money something no the reward is into the good mark you got you learn something and you had a plus that's a reward. And it's difficult for people working in open source because the reward is having a good product a product that people love people that people use that's the main reward. And talking about yourself bragging about your skills you know being put in the front page that's uncomfortable. So it's difficult to find the right ways to put people under the light but it's also difficult to put those people to put them under the light because they don't feel like they deserve it or that's not the main point of their engagement they just want to help. Yeah, I think without giving anything away one of the responses that we've received from the project. Basically is all passion all heart you know just loves helping wants to be part of it just loves Jenkins because of how much it's helped them and how much like how much they've invested into it so it's like. They're very aware of all of this you know and it's not to take anything away or to say like oh you're not being appreciated but you know that is the kind of dedication passion that like drives all this open source development. And it's just like acknowledging that aspect and sharing that giving that effect that infectious like joy and spark to other people maybe like that's all it takes or, you know, I feel like the interviews and questionnaire and responses are pretty like low risk in in terms of that person being highlighted and stuff. Yeah, there there's going to be some fanfare associated but there should be the work that they're doing is unreal and necessary and huge and like just pushes us forward. It gives us, you know, gives us more work to do. It's the driving force so it needs to be appreciated these people need to be appreciated and highlighted, like highlighted is one aspect of it but the appreciation needs to happen for. I mean, I know I feel better and will continue to do things when I know it's appreciated. Yeah. So, but yeah, the project's coming along really well, we're, you know, we're getting a lot of good stuff. We're in a good really good place with it. It's just a matter of getting it published in live, more than anything else. And yeah, once we start publishing them they're just going to be coming out on a, you know, hopefully regular cadence of, you know, by every other week. And here you say be weekly by weekly. No, no, you didn't say that regularly. It's a sufficiently vague term to say that we will make it. Yeah, whenever we can. Yeah, it will be out regularly. But yeah, this way we everyone gets a time their time to kind of shine in the spotlight without being overwhelmed. And yeah, I think it's just nice to give that personal aspect to to these as well. For me joining an open source community has been really fun and great because I get to interact with a plethora of people I've never met in person before and from all different walks of life. And I might, but I might not ever get to connect with them on a personal basis. This is this is a really nice opportunity to get that connection, even if it's not direct with that person, you can still, you know, that comfort level is increased by just knowing that, you know, I found out one of our top contributors is super into music and is actually has been playing trumpet for 15 years. Oh, I don't think I would have even asked that question. So it's really, it's really cool to get insight into someone like this. And yeah, I have high hopes that it's going to be a really nice recognition project and that the contributors will feel good after this. I mean, my angle is making sure that the contributors feel appreciated. So that's really all. And more or less discover the real human being hiding behind the contributor. Yeah, yeah, exactly. That Butler is the face of Jenkins but all the internal body parts and stuff like that. They're all people. Anyway, nice one. Yeah, we won't get into which body parts or who. Anyway, okay. I'm not the brains. That's all I'm saying. Anyway, so that concludes the agenda I had for today. Thanks for sticking around for the extra time. I appreciate it. Thank you for the discussion today. Thank you. Really nice. The recording will be up in 24 to 48 hours. And we'll be back next week. Until then, take care. And thank you as always.