 Okay. Welcome to Jenkins documentation office hours. Today is April 13th, 2023. This is the EU and US edition. Today we have myself, Mark Waite and Alexander Brandes. Thank you for joining us today on the agenda. We have an agenda topic that Alex will share with us. A few blog posts to highlight that have been published in the last week or two. Google Summer of Code update. Some recent blog layout improvements that were submitted by Jan Firechick. Image contributing guidelines that have been added recently and in addition to that some new documentation guidelines I've submitted for consideration. One poll request to discuss. Something that we've been working on and could just love to have some community discussion on. Alternative options to handle stale poll requests. If that becomes something that we want to talk about. The end of life notifications in Jenkins core and this is something that Mark's got a concept for that we can discuss and talk through. And the improved CI process for Jenkins.io that airway has merged and saved a bunch of space and time for. So talk about that. Reducing the number of open poll requests in general. And the early end of life for CentOS 7 in the Jenkins project provided we have an opportunity to that point. Is there anything else that needs to be put on the agenda or any questions? Alright. Cool. So Alex, you want to actually start us off today? Yeah. Let me go ahead. Actually, I was a bit in a rush earlier. It's not about Jenkins.io. It's about the repository called Jenkins.io. Maybe my comments slipped. So yeah, that's basically what I'm going about. And over the past few months, I proposed over 90 pull requests that have which have already been merged. And I'm pretty surprised by that. And I've also reviewed over 155 pull requests just in the Jenkins that I over repository. And the contributing file says that the decision of adding more people to the team is up to the documentation officer. And Kevin, that's why I would like to ask you if you are fine with me joining the copy editors team to continue my doing on a more official area. Oh my gosh, absolutely. Because my currently my permissions are I think inherited from the board group or some sort of that. Because I think I don't I'm not in any moderation group often because I all at the moment. So yeah. So Alex, you've already got merge permission though, right? Yeah. Okay, good. All right. So so this is so this is not actually giving you any more permissions. No formalizing that the your membership in a group. Yes. Good. Okay. All right. Yes. So excellent. Yeah. And I'm absolutely inclined to just say yes, automatically. I don't think there's any doubt or question to my mind. And I don't think Mark has any either. But no, that's awesome. Alex, thank you so much for bringing that up asking. Obviously, you have more than enough permissions and you're part of the governance board. So it's yeah, making sure that that's at least formalized and put clearly would be nice just for visual sake. But yeah, no, thank you. And thank you so much for all of your work and contributions, reviews, everything. Just since I started last year with Jenkins and the community, you're one of the names that's come up at infinite. So I yeah, just thank you for everything. So I object to the use of Latin, particularly when dealing with someone from the German education organization. Alexander probably actually understands that infinite. So great. Ruins a while. I try, but noted. Cool. Anything else on that, Alex? Or is that? No, that's basically it. OK, so just to bring just to bring the precise detail, then what I'm going to do is I'm going to submit a proposal to Jenkins developers. So I'm sending the mail now Alex Brandis as a copy editor, because that's what the process says. If I remember right, propose to add Alex Brandis, not my fault. As a copy editor in. Jenkins that I or repository. Already has merged permissions and has already submitted. You said it was 90 pull requests. Yes, 90 pull requests. And has Mer and has reviewed over 150 objections. If yeah, approval. Question mark. OK, great. Sent. OK. I'll link to the message in the notes so that we've got it. Thanks, Mark. Thank you very much, Mark. Yeah, I just got it perfect. Awesome. Well, great news to start the meeting off with. Now I'm really excited. So next up, just a few blog posts that we're sorry. Go ahead. I'm in a I'm in a cheat now, Kevin, because we've got Alex here. I want to shift the agenda. I'd propose we shift the agenda around and bring up some specific topics that you and I have talked about. But Alex, I'd like Alex's feedback on so the alternate ways to handle stale pull requests and the end of life notifications are two topics. Alex, where I wanted your feedback. Well, sure, let's go ahead with that. OK, so so just. All right, so linking. All right. And now, because it helps me with notes that they are in the linear order that we will discuss them, I'm actually moving them up, Kevin. OK, sounds good, Mark. All right, good. OK, so first first idea, Alex was. We've got a long list of pull requests in the Jenkins that our repositories. One of them is all the way back from 2019. The content is actually still useful, but none of us have had the time to go in and correct the errors that are in the content. And it's beginning to become distracting that we've got content there that we just don't have time to work. And there's no way to flag to others that they might take it to work on it. So what what Kevin and I were discussing was a possible rule where we say, hey, if the content of the stale pull request is not valuable, just close it. Right. Junk pull requests, we just close. That's easy. If it is valuable, that needs more work than we're ready to do over the next, say, few months, then we create an issue to track that content that mentions the pull request. But we close the pull request so that the pull request pool is the things that are actively being worked, not the things that have just piled up because we haven't had time to do anything with them. Your comments, what do you think is that I know Daniel Beck really dislike Stalebot and I agree with his dislike that Stalebot by closing it just because we've not done anything isn't fair, but I'm trying to strike a compromise here to get it off my list. Sorry, Alex, go ahead. Yeah, I'm with Daniel there. I think Stalebot is the least acceptable and most hostile way to close issues on pull requests, given you're basically feeding the user with a copy paste answer and getting ahead. Hey, this has been inactive for 30, 60, 90 days and so on. We will close it and that's it. But you don't need to say what for that. Can also do this by hand and has basically same bad effect. But yeah, in the meantime, I opened the pull request on Jenkins.io just to get myself into the scope real quick. And I see on the second page, there are very a lot of pull requests labeled as work in progress, wiki migration and unresolved merge conflict. But I wouldn't say that is necessarily a bad thing because in core we if you go to the third page or to the last page, we have that much drafts and pull requests needing attention. Basically, I think you can face a similar problem in many open source projects sized off Jenkins. If you go through the larger page, latest pages of issues and stuff like that. How to address those things in core, we have a label called stalled, if I remember correctly, which Basil introduced or I don't know, at least Basil used it a lot to mark pull requests where the author is inactive, unresponsive or didn't address the feedback proposed in a timely manner. Like let's say one or two months and they basically didn't do anything. So we put the label on it and that basically means the pull requests need some work, but we allow others to take over like cherry pick the commit into their branch and fix it up, make a new pull request and say, Hey, this is a progress for that. And this pull request supersedes the other one. Please review it contains the review feedback and so on. Followed on this day, followed on the start label, we have the proposed for close label, which we don't use that much. But the point of that is to basically really close an issue after waiting a long time, I don't know, not responding to any feedback at all. So, so for me, the stall, oh, go ahead. Yeah, this is what we have in core. I don't know if that is applicable to Jenkins.io, given the majority of contributions aren't that much technical rather than text file or documentation. So you don't need to have tests or something like that to cover that. So it would probably make sense to, I don't know, have a label that says possibly or just put the pull request in a draft state and say, Hey, I'm working on that. Please don't review that. And I will get back to it at the later point. Or if you reviewer says. This pull request needs some work. Please address this and this and this or at least providing a compelling list of feedback to submit. I can go off instead of saying, Hey, I don't like this or hey, this is a bad practice without providing any details. So I like the you you've indicated one more thing that we could use for state transition, which is draft or non-draft. So so that's one I hadn't considered. So the now the so I think the OK, the inactive submitter is the is the most common case for the old pull requests on Jenkins.io. And and then I'm confident they're not coming back, right? They submitted it long ago. It's it was submitted as part of Hacktoberfest or as part of some other event. And they're they've not been involved in the Jenkins project for a very long time. So with inactive submitter, the stalled label would be an easy one to tell me, oh, I've got an inactive submitter and then proposed for close could also be used, although I worry there. We lose the fact that or by closing it, it becomes completely invisible, right? It no longer is visible to anyone that they could include it as content. So maybe it's stalled is OK. And we just accept that they're going to be open. And that's closer to what Jenkins Core does, right? I think that was what you were pointing out is that it's OK that Jenkins Core has a number of open pull requests, many of them that aren't getting progress while we go through this labeling process. Yeah. OK, I mean, Kevin, OK, I mean, we don't need to accept every contribution because not everything fits into our stance of Jenkins or Jenkins that I own that case. So proposed for close isn't just. For stalled pull requests, but is a good start, but needs a bit fun tuning here and there to bring it on state and say, hey, this is good. We can approve and match this, allowing others to take it to take over in case the submitter is not responding or doesn't want to address the feedback in a timely manner because there's no real benefit in keeping a pull request open for six months and continuously pinging the submitter asking, hey, can you fix this? If they don't want to, we can't force them to do that. So, right. Yeah, and I actually I like the stalled label a lot. I did check Jenkins.io does have the stalled label in the repo. So it can be used. We have it's in place, which is great. And I like all of what you said, Alex, a lot. I think that's a really good way to handle all these without closing them and, you know, locking someone out from that. I did have an idea when Mark and I were talking and this was just based on my experience with Jenkins.io and new contributors in that they are typically more likely to go to the issues page than the pull request page. If they're just getting started or joining the project, maybe taking some of the older pull requests that are worth it and have value and putting that into a new issue could be a way to get eyes on it while still holding on to that information and data, but also kind of respecting the idea that if someone's not going to work on it, someone else could or something like that along those lines just in an effort to keep it still, you know, live, obviously. Yeah, that's also like an interesting approach. We could try it out like create an issue based on a pull request, go go the reverse order and say we have that someone contributed that. But this is incomplete because it lacks ABC and D if someone is interested in contributing that, please go ahead. Be our guest. You could see how it works, especially during Octoberfest. Oh, oh, right. Maybe that's the time to do it, is we say, yeah, good, good idea. Consider that as Hector Fest. Spread because to be fair, I would rather see a few Octoberfest PRs not wrapping around type of fixes here and there because I'm already approving too many of them. So if the one says, hey, I'm a new contributor to Jenkins and I would like to pick up the topic based on someone else's work. I think this is something that could possibly work out, especially if you have already a standing point from where you can take over. Right. OK, good. Yeah, that'd be great. And especially where Hector Fest is a good entry point for so many people. That's also a great entry point is having some base to work off of like that. So that'd be a great call. Yeah, I like that a lot. Now there's OK, I see a danger in that one, in that many of at least several of those really old pull requests require a level of technical knowledge that a Hector Fest first time contributor won't do. But the simple answer there is we don't label them Hector Fest. Mm hmm. OK, good. Very good. Thanks. So that was all that I had to discuss on alternate ways to handle stale pull requests. I think the action item is I'm going to I'm going to apply stalled labels to a number of the ones that I know are stalled. First test and and we'll watch and see. And then we can consider in future sessions should we assign some of those the Hector Fest label. The stalled label is easy, right? It's clear for me. I know which ones are stalled. Great. OK. So, Kevin, are you OK if we go to the next topic? Absolutely, Mark. All right, so Alex, this one is one where it's more of a software slash user experience design question than anything. So we've got a general purpose challenge. Sentos seven is end of life in June of twenty twenty four Alpine three dot fourteen is end of life in April. Ubuntu eighteen is end of life in end of May, etc. There are these different different things. Some of our containers need to be end of life. And so we've got a notion that I would love to not just have blog posts as the only way to inform people that something is end of life. I'd like an administrative monitor that says we've detected that you're end of life on something that's important to the Jenkins project in your environment. The idea is so, for instance, we detect inside Jenkins. You're running on Sentos seven and it will be end of life at this date or Ubuntu eighteen will be end of life May thirty one twenty twenty three. We're warning you now that the Jenkins project does not support Jenkins running on operating systems that the vendor does not support. So the concept was we need a way of detecting that we're on that thing. And then we need a way of saying, here's the message we should display before the end of life. And here's the message we should display after the end of life. And the thought I had was this notion of a general purpose admin monitor that is fed by data files in a directory in Jenkins home. Those data files are delivered by the Jenkins install process. And or yeah, maybe their resources built into the war. I guess they have to be resources built into the war, don't they? But one way that they come with Jenkins that say, here are some various end of life things that we need to do where if we find the file on the system, ETC OS release and it has the contents that match Ubuntu eighteen, we know this admin monitor should be displayed. Now, the question, go ahead, Alex, the question to you is, what do you think? Yeah, that sounds similar to our approach that we used when we want users about our transition from Java eight to eleven. We also use the administrative monitor there alongside some other communication channels, of course, but it's definitely an interesting and to me right approach to also display that process admins right into Jenkins itself to say, hey, this OS is going to be end of life then. But the Jenkins project supports it until then so they can plan ahead and have dates that can actually go off rather than following a blog post that takes place likely a few weeks well before or after end of life. So this is not really optimal to plan ahead. But, yeah, like you mentioned, we have various OS that are going to be end of life very soon in Jenkins and very soon end of life itself. And I think an administrative monitor would definitely be beneficial about the data. I mean, if the data doesn't change, we can just build it into the warfile. Otherwise, we would need to seek a way to keep it up to date. But I don't think that would be a concern. Because I don't know unless you thought unless you thought about shifting support dates. But if that's not the case, we can just have a static file in the war directory for sure. Because if not, we would need to find a way to update that file to the end user. I think to get my concern, I do. And you you just described something I had not considered. I hadn't thought about the scenario we had with Java, the Java 8 to Java 11 transition, where we actually adjusted the dates. We adjusted the dates after initial publication. And so that that's a good, good question. My initial thought is I don't want to have create a service that provides updates to these to these definitions. But you may have highlighted, we really need to think about such a service at a minimum in the Jenkins enhancement proposal that I want to do for this. I should explicitly say this is intentionally not using a service, though that could be added in the future to allow us to do incremental updates to this, just like we do with the the plugins in the update center today. I'm not sure how far the update center supports it, but if it supports transmitting, let's say, a bit more external data, you could probably hack it into there now, OK? Yeah, then please just forgot my concern. I would be I would be scolded so directly by Daniel. It would be just, no, we we're not putting that kind of stuff into the update center. Thank you very much. It's already too big. Yeah, OK. Yeah, but in case we need to shift dates, we need to find a way to update those files, because otherwise we will have people yelling at us. Why wasn't I informed? Why did I have the old dates and so on? I don't think that is the desirable outcome either. So right. Yeah. Well, and it's it's a it's a valid. OK, so some some things that are involved there, then I had originally envisioned it being multiple files in a directory, but realistically, because it's bundled inside the war file, it doesn't have to be multiple files. It could be a single single collection of data because it's specific to the version Jenkins version we ship, right? We at the time we shipped that Jenkins release, we knew these things. The next release, we may know more things. Yeah. If I remember correctly, the dates for the Java 8 and of live thing were basically just a message file, so anything works here. Right. Good. OK, thank you. Great. That was the feedback I wanted. Thanks very much. Any any other insights that you'd like to offer on that end of life notifications idea before I continue with developing it as a Jenkins enhancement proposal? This will not be good. A rate of 18 and sent to us even the better. Yes. OK, I have a separate jet to accelerate the end of Centos 7. That's a long, long thing on Markweights passion list. Yes, absolutely. OK, Kevin, thanks. That topic is done. Yeah. OK, thanks, Alex. Thank you so much. Great. OK, in that case, let's get moving. Blog posts. So we did just publish the March newsletter. So all the lovely updates from March from the various SIG leaders are nice and convincing here. Again, always want to thank Roxanne from CDF for the image headers. Really lovely and help bring a little bit more personality to it. Another blog post that we recently published is regarding digital ocean and there's continued sponsorship of Jenkins. They have graciously extended to us an additional eighty four hundred dollar credit for the next six months. We had some heavy usage in March that was unexpected and relied on due to some other issues we were fixing. But digital ocean came through and just showed us that they're here for us and gave us the credit to help get us through the next six months and that will get us to roughly about the year mark for our latest sponsorship with them. So nice time to talk about it and just something that we want to share our unending thanks for from digital ocean truly just amazing and super helpful in making sure we can dedicate our resources accordingly. The next one is that so Bruno Rockman, who usually is here with us, he's currently at Devox, France, giving some awesome talks and information out. But he has the second post about building Android apps with Jenkins. So this was just published last week. If you want more information about the relationship between Jenkins and Android apps, great place to start. And Bruno will be continuing this series as we go on. So more to come on that. And then the last blog post I wanted to highlight today is that we just posted this today. It's about Jenkins at CD Con and GitOps Con this year. So CD Con is happening May 8th and 9th. Mark's actually going to be there taking part in the graduated projects keynote panel, so exciting representation there. Alex is going to be there. That's right. Thanks for this foundation. I can make it. Awesome. That's so exciting. And I know Gavin might be there to at some point. So just really exciting. Glad to have everyone participating. That's going to be a really good time and we'll be announcing the Jenkins Awards winners there as well. So if you're going to be there, you may win something. You never know. But just again, super appreciate this continuous delivery foundation for providing this and sharing this and signalling that how much excitement there is for this year. Quick update for Google some of code. So in total, we got about 55 valid proposals, which is far more than we've gotten recently, which is great to hear. That just means a lot more review work for our mentors and our leaders. So they've been hard at work reviewing and grading every proposal that's come through. They're still working. But thank you to all of the folks that are helping with that. The recently we had a pull request submitted by Jan Farcheck about improving the blog layout. This is now live. We got some really good feedback from community around this. But instead of having it listed down in the page, we've now got these nice little cards and blurbs and highlights showing the authors, the publication date. Just a nicer look overall to the Jenkins blog. There are some things that we have to, you know, look into and address at some point, background color versus the actual background of the page, making these a bit more uniform, things like that. But ultimately, this is a really great facelift for the Jenkins blog. And additionally, the Jenkins dashboard or the Jenkins homepage because it's present here as well. So just across the board, nice little updates and quality of life improvements overall. Thanks to Jan for, again, contributing all this and working on this. We really appreciate that as well. And yeah, the image contributing guidelines. I submitted those last week. They have been merged now. So we got I got some good feedback from Alex and other members of the community. Alex has actually gone out of his way to go ahead and compress 400 images. I'm still working my way through that, but I trust stuff. Yeah, it's just a matter of making sure everything looks OK. Yeah, that was that was that was a mechanical translation, right? Alex, you wrote a script that did the work. This was not. Yeah. Luckily, tools exist for that and you don't have to do it all by hand. Fantastic. Great. No. And yeah, it saves about 37 megabytes on the page. Great. Amazing. More space. We save the better. Thank you, Alex, for that, even if it's something that you scripted. That's that's still something that's a lot of work either way. So and then just today, I submitted some documentation guidelines. This includes some just general practices that I've been working on and developing myself, as well as things that my fellow documentation writers are sharing. And I wanted to make sure I included the inclusive naming aspect in the guidelines. That is something that we've been working on for quite some time now. We've had several projects in for that through Sheikot Africa and various other areas. There's still some places that could exist, but we want to make sure that we're not adding more to that and that we're using the updated naming. So things to consider, I know. And thank you to Chris Stern for reviewing and sharing some feedback on that already. I did see he added some information there as well. So I'm going to be reviewing and going forward with that as well. Now we are at time. So if there's anything anyone wanted to discuss further on these last few topics between there's one pull request that we could look at in a couple of other smaller notes. But I want to be respectful of everyone's day. Is there anything that wants to be called out? No. OK. So in that case, we'll table these three for the next time and continue our discussions at that. In the meantime, I'll also go ahead and stop the video here. The recording will be available in about 24 to 48 hours. And as always, thank you for joining and really great to see everyone take care and have a great weekend.