 Hello and welcome to Jenkins Docs Office Hours. Today is November 30th. This is the EU U.S. edition and today we have myself Kevin Martins, Mark Whee and Brnoe Verrachton on the agenda. So last up latest LTS was released just a couple weeks ago. Contributor Spotlight, the Jenkins Contributor Summit, Fozdom. Oh, yep. And I think we're on the same page, Mark, because I do have the sponsor attributes, one item down. So good to see. So yeah, adding sponsor attributes to Jenkins.io. The packaging repo recently had an update to support UNIX domain sockets. GSOC 2024 preps ongoing and the version documentation site for Jenkins.io. Mark, you mentioned there were some other things you wanted to add to the agenda. Are they there or is there anything else to add on that? You got them. Okay, perfect. All right. So starting off. So again, LTS 2.426.1 was released on November 15th. Everything went well. And Darren and Mark did a live stream the next day, going over all the new features and fun stuff. LTS 2.426.2 is set to release on December 13th and the release candidate was actually pushed today. So that is available via the developer mailing list. Next up, so the Contributor Spotlight site, which is something that we recently started discussing, is now live. This is fantastic. This is the result of months of work and research and determination by Alyssa Tong, Bruno Verrachtin, John Mark Messin, myself. Chris Stern has done so much work on the site making sure that this is working and live. There's just been so many folks working on this and helping with this. Just thanks to everyone. This is fantastic to have. So the Contributor Spotlight site is live. And our first contributor to Spotlight is Alexander Brandis. So throughout the familiar with Alex, he's part of the Jenkins Government Board. He's been part of the Jenkins community since 2019. And yeah, he's just been a really great pillar to have as part of the Jenkins community for the last handful of years. So thanks to Alex and really happy to be able to Spotlight him. We're going to be releasing new publishing new contributor Spotlights every two weeks. We want to give time for the existing contributor to have time and be highlighted. Give some room just in case there are other announcements that need to be made. We don't want to take away from anyone. The idea is we appreciate this work that goes into keeping Jenkins the way it is and keeping it on the cutting edge. We're highlighting. We're appreciating. We want people to know who these contributors are. It's been announced to be a LinkedIn, Twitter. We have a blog post on the Jenkins blog and it was announced in the Gitter channel. So we are putting this stuff out there. We're still collecting responses. There are more to come. I still have to do mine. I know Mark just did his recently. There's a couple other folks that are still waiting on. So there's going to be more content to come. But we do have enough right now. That will be good for a little while. We are generating feedback and suggestions review from anyone that is willing to look at it. We've been able to update and fix some of the mobile formatting issues. Thanks to Christopher for doing all of this to help keep the site looking nice and presentable and everything they're doing. They're up very late doing a lot of work. So I just have an ending thanks to Chris for all of this. And then something that just came up in the advocacy and outreach meeting we had earlier today was that the Jenkins contributor spotlight page, the way it's formatted or the way it's set up now is if you click on the Jenkins name logo here, it keeps you on the contributor spotlight page. Whereas if you were to go to the blog, it will take you to the Jenkins.io home page. This functionality is present in other areas. So plugins.jengens.io, the same thing happens here. If I go to GitHub release plugin, it's going to just take me back to plugins.io. Same thing with stories. If I go to any of the user stories, it's going to take me to stories.jengens.io. So the question's been raised, should this be the case? Or should the contributor spotlight Jenkins logo navigate back to Jenkins.io? Alyssa had pointed out that if someone's not aware, they would have to click on the blog or the documentation or something else that is part of just Jenkins.io and then they can use that to get back to the home page. However, the contributor spotlight functionality is consistent with other sub-domains that we have in the infrastructure. So yeah, curious. Marc, Bruno, what do you think? Do you have thoughts on this or your preferences? In fact, I've been thinking for you that this was kind of a bug or maybe a bug in me or in bug in the website. I was not able to decide, but it's disturbing for me to click on Jenkins and not go to Jenkins.io. It always has been, but I didn't find the time or whatever to file an issue or something. I was not sure if that was a problem or just me not understanding how the website supposed to work. So for me, yes, I would prefer to have to go back to Jenkins.io in all of these sub-websites whenever I click on Jenkins, but adjust personal taste. And I think my personal taste is the other direction because when I'm on the plugin site, I want to stay there. But it's a fair point that it's a preference thing, right? It's not an obvious, oh, it should always do this. I think pretty commonly top left takes us to the root of everything, everything. And so if you navigate on contributor spotlight and open up Alex Brandis' specific page, now you click the top left, it takes us home to contributor spotlight. Yeah. And likewise for plugins. So it's behaving at least in some fashion as conceptually consistent, but I'm not sure that it's consistent for what users expect. I don't know. I don't want to open a kind of words, but couldn't we set something with cookies, you know, like some website do with dark background or light background? Probably could, but I don't think that's a level of, I don't think we want a preference management UI on the Jenkins static website. Yes, yes, we certainly could, but I would, I would lobby against it just because let's, now that's just me, but I'm, there's an element of mind that's lazy and says, I don't want to, I don't want to mess with this, if I don't have to. If it's not broken, don't fix it. Well, and if it should go, if it should always go to www.jkins.io, then we make the change in the top level components page. And I think that's a good thing to have as a discussion in, in that, in that context. Thank you very much, Mark and Bruno for sharing. I'm actually pretty torn on both sides. I can see why it makes sense to have it go home. And I also get that it's doing the same thing other pages are doing. So, yeah, should I just open an issue for this mark on the Jenkins.io repo and we can have discussion there? Yeah, I think that's a, that's a good way to approach it. Yep. Okay. Yeah, then I'll go ahead and open up an issue on navigate for the navigation of that link. And we can have more discussion there. I think that that would be really helpful and we could get more opinions because right now we're at a stalemate and I'm not helping. So, yeah. Great. Any other thoughts, comments, concerns about the contributor spotlight site? Bruno and Mark, before we move on. Okay. Great. So next thing on the agenda is the Jenkins contributor summit at Fosdom is happening. So, Jean-Marc Missin has written up a nice blog post explaining what the Jenkins contributor summit is, important dates, information, etc., etc., who to contact. So, all great information, really important. And then we also have the Jenkins Meetup page actually up now. So, if you are planning on attending, you can register that here and share that with us. And so, we'll know who's attending and who to expect and who to plan for and everything like that. The folks right now listed are hosting. So, we actually have gotten one more attendee. That's nice. So, great. So, great to see you there. And yeah, obviously there's still some time to register. Fosdom is free to attend. So, if you are in Brussels and you want to go, you feel free. Next up. So, we just had a packaging pull request merge. And this pull request adds support for UNIX domain sockets in Jenkins. This user has submitted the pull request. They've explained the purpose and the reasoning for the update. And so, what I've now gone and done is created separate tickets for each reverse proxy configuration. This creates new, because it's now supporting the UNIX domain sockets, there's additional steps and information that needs to be added to the reverse proxy configuration pages. So, I've created a separate issue for each one. And for the Apache one, specifically, since the user contributed using Apache as their example in their kind of building test, I've tagged them in the Apache ticket to see if they'd be interested in adding that documentation. The rest, we would want to have people with engine experience or how proxy experience, Pomeranian experience, et cetera, kind of making sure that this is all going in there correctly, that it's not upsetting anything or contradicting anything that already exists because we do have what works already. And IP tables may be less interacted with one. It may not be as high of a choice as, say, Apache or Ingenix. So, there may not be action on that, but Apache and Ingenix are fairly commonly used and pretty popular, so more likely that we get some action there. And then, Mark, anything else on that on the reverse proxy stuff or anything like that? Oh, so the work, the option is there to do the work, and this is non-trivial doing this because you've got to know enough about the reverse proxy to configure it to use Unix domain sockets. And you've got to know enough about System D to configure Jenkins to use Unix domain sockets. And then, you've got to be able to write it into the text. So, the issues are open and they are not great candidates for a brand new contributor. Gotcha. Yeah, that's good to note. That's not just a simple adding some text and calling it a day. It does require verification testing, et cetera. Right. And the problem is if a brand new contributor picks it up and does it, then whoever's reviewing it has to do the verification as well and then waste time if the contributor did it wrong and didn't do a good job of verification. So, much rather we not have someone with no experience pick one of these up and offer a bad pull request. It wastes time. That experience is overall for the submitter and the reviewer. Right, exactly. If we have to teach the submitter how to configure a reverse proxy in one of these web servers, we've now wasted an awful lot of time. Right. Great. Thank you very much, Mark, for adding that context and explaining a bit further on what we're looking for in that regard. So, next up on the agenda, we have a request to adding sponsor attributions. So, this is an issue that was opened up by Mark. A friend from JFrog had asked that we include JFrog attributed as a sponsor in the downloads page. We're using artifactory. They have every right to want to be highlighted as a sponsor. So, this then took on the form of a discussion where Basil had said, suggesting having a dedicated sponsors page, not unlike other projects and other platforms. So, that's where we're at at this point in time is Basil's created a draft sponsors page. So, we have this here to, I think I can go to the view, or is it already linked in here, Mark? It is. At least that's the prototype. Right. Yeah. So, here's the deploy link to preview. So, basically, we have to figure out or determine what levels of sponsors everyone is, assign them accordingly on the levels here and we'll have a dedicated sponsors page to showcase all the sponsorships that Jenkins has. On top of that, there's also discussion around whether they are separate sponsorship attributions on the download page itself and the root page itself, in addition to having the dedicated sponsors page. And based on JFrog's reasoning, I think it makes sense to have separate attributions as well as the sponsors page. Whether or not they're included in that, because the point being made was that JFrog is not necessarily being used for downloads specifically. So, maybe not including them there, but whoever the downloads are sponsored by including them there. Well, you're describing the challenge on the downloads page. In the original issue that was submitted, it describes that the downloads page, all of the links from that page go to locations that are not JFrog provided. And so, however, JFrog provides a lot of downloads for us because all Jenkins development is critically dependent on JFrog downloads. So, the downloads page is a good high visibility place to talk about who provides our binary archives and who provides our binary archives for developers, it's JFrog. For users, it's DigitalOcean and these various mirror sponsors like the Oregon State University Open Source Lab, Xmission, Tsinghua, and Cervana. So, yeah, the discussions are there and we don't have a final solution yet, but I like and agree with the idea that we need to set levels and place sponsors here. Right now, if you go to the root page, www.jankins.io in a separate tab, we can look at what we have right now as a way to show our sponsors. And this is not nearly fine enough granularity, right? I think Basel is correct to say that we need more levels, because the contribution from the OSL, the OSU Open Source Lab, by the way there, yeah, the Oregon State University Open Source Lab from OSL is very different from the contribution from CloudBees. Likewise, the Red Hat contribution is very different from JFrog's contribution. So, we've got levels that we need to highlight and I think Basel's got a good idea. If you go back to the list in the document, he so all the way back to the meeting notes. Okay. He suggested Anker, Premier, Partner, Supporter, Associate, and Mirror. And that sort of aligns with at least some portion of the three levels that the CD Foundation has, Premier, General, and End User, we could find a way to map those. I think we need more than three, I'm not persuaded we need six. And that's where the, okay, why am I saying that? Because there are criteria that each of these have. And what I haven't done is express the criteria for those levels. And the criteria are the thing that really matters, right? What would it mean to be Anker? And what would it mean to be a Premier? And what would it mean to be Mirror, etc.? So, can we describe each and every support level by money? Or are some of these services, some of these support, do they always imply some money or other services? We don't know if that's the amount of money it corresponds to. You hit it very, very well, Bruno. Many of these, many of our supporters, we do not have a direct cash amount that we can say, because let's take two examples, GitHub and JFrog, right? Both exceptional supporters of us, both really doing great things. GitHub hosts 2000 plus repositories for the Jenkins project, provides private hosting for security repositories, provides all sorts of capacity for us, but monetary assignment of that value is difficult to do. JFrog likewise, they provide the entire service, repo jankinci.org, and they don't tell us how much it costs them to do that. They just say, here's this service, we provide this to open source. So, but we can, part of me says, we could do a financial approximation and say, hey, if we bought GitHub Enterprise for the 600 plus Jenkins contributors, it would cost us this much a year. And that then would give us a financial approximation. Others, it's more difficult. How do we do a financial approximation for the mirrors hosted by the open source lab at Oregon State University? The answer is, we could play approximation games with bandwidth use, but it gets complicated. So, there's a piece of that where I think we can't do a simple financial mapping. There are others where I think we can do a financial mapping because we have exact amounts, the continuous delivery foundation, we know what their contribution is to our infrastructure. Others likewise, CloudBees donates a significant amount to Jenkins project infrastructure. CloudBees donates a lot of people to work on Jenkins. So, there you have it. Does that tell us why we don't have an answer yet? But I think you've got a framework for a discussion. Thank you, Mark. Thank you very much, Mark. That helped clarify a lot and I think helped add a lot of context that I was potentially missing or just not didn't have. So, yeah, thank you very much for helping paint that picture for everyone. And yeah, there is a happy medium between three and six, I think, four or five. Well, and I'm not sure that the Basel's labels are interesting labels, but I need to do some research elsewhere to find are there other labels that other projects use that might better map to us. And I just don't know. The word partner, for instance, is loaded with meaning and has caused grumbling in the Jenkins project in the past when anyone tried to use it as a way of saying we're a Jenkins partner because Jenkins does not establish partnerships. Therefore, the word partner may be overloaded. That those kinds of things. Yeah, definitely. So it's going to take some time, but we'll figure it out. And I think it's a great, I think regardless of what the outcome is, it's a great idea and something I should absolutely implement. So, thank you very much, Mark. Next up on the agenda, Google Summer of Code 2024 prep work has begun. It's ongoing. Chris Stern is leading the Google Summer of Code 2024. Really happy to have them doing that. Thanks again to Chris for all the work. I can't say it enough today. But yeah, so work's being done there. Project Ideas page is live. We've got about 14 ideas. Whether they all make it, we'll see you about that. But we are looking for mentors specifically for any of the project ideas. By all means, if you feel intrigued, curious, or even slightly interested, check out the projects page. See if there's something there that you might be interested in. The more support, the more people we have, the better it's going to be, the more likely it is to get picked up as a project. And you know, at the end of the day, if one of the projects doesn't work out, that doesn't mean you can't join a different project and hop on there or become a mentor for a different project if it's remotely interesting to you in that sense. But more information can be found on the Google Summer of Code page in Jenkins. The projects page will link to other project ideas and have more information on each of those. And you can see who's already potentially signed up or on board for that project. And then the last thing I have on the agenda for today is the version documentation site for Jenkins.io, still being worked on by Chris Stern and Van Dieet Singh. Van Dieet's working to update the documentation copy from the latest changes that we've been going through on Jenkins. And yeah, they have the preview site available as they have had. So it's looking really nice. And yeah, just looking forward to that. And that covers the agenda I had for today. Did anyone else have anything they wanted to add or discuss before we wrap things up and stop the recording? I just wanted to tell you about a small anecdote. There was a guy on community.jnk.io showing off an article he had written on Medium about Jenkins. So I dragged him by the call and said, hey, what about making an article on Jenkins.io blog itself? He said, oh, yes, thanks a lot. I'm honored and so on. But I thought it would be, you know, the contributing guide would be kind of intimidating. It's not that easy to have a working environment on your machine to get Jenkins.io up and running. But he did it in the heartbeat. And there's already a draft PR existing on Jenkins.io. So I'm pretty happy with the way all of this went. So yeah, the contributing guide is kind of working. And that's cool. Thanks, Ron. I'm glad you pointed that out. I did see that earlier. I've been working on the contributor spotlight stuff. So I didn't get a chance to review it yet. Really cool that it's someone cross posting from Medium to have that visibility come over and kind of expand upon that. That's so cool. I'm really happy to have that. Thank you for advocating and encouraging them to do this. Great. All right. So that covers everything today. Yeah, we'll stop the recording in just a moment here. It will be available 24 to 48 hours, as always. Docs Office Hours Asia is cancelled later today. So that won't be happening. We'll be back next week. And yeah, until then, take care. Stay safe. As always, contribute to Jenkins whenever you feel like it or can. And we'll see you then. Thanks.