 Welcome to Google or Jenkins Docs office hours. So used to running other things. Welcome to Jenkins documentation office hours. It's February 17th, 2022 reminder that we abide by the Jenkins code of conduct. Topics for today, Jenkins is the way and some questions that Gavin Mogan had. She code Africa contributon, news, good first issues where we'll do a live bug fix is my proposal anyway. And then a topic on adding a troubleshooting page and topic on Linux installers and their change from init to system D. Any other topics that need to be added to the list? Let's get to me. Okay, all right. So first topic then, Gavin Mogan joined the docs office hours last week during the Asia time zone. And we did a detailed review of the content for Jenkins is the way and it's looking really good translation. So that our conversion, I guess is the best way to say it. So what he's done is he's converted it from the, from the WordPress site now converted to, I believe ASCII doc that we can maintain his code. Nice. And what he noted is, hey, it doesn't have to actually go on to Jenkins on to www.jenkins.io. And if we put it there right now, it will, if we add it there, it will roughly double the size, the size of the Git repository and the Git repository for Jenkins.io is already quite large at 60 megabytes. So it will go from like 60 megabytes to over a hundred. And he suggested at, and I think also a suggestion from Oleg Nanashov, well, we could consider putting it at a different URL. It's been at a different URL. Today it is at Jenkins is the way dot, oh, I forget, what is it? I.O. Dot Jenkins.io? Jenkins is the way dot I.O. Dot I.O, okay. And what we could do is Jenkins is the way dot Jenkins.io. If you'd be willing to do that, Alyssa, and then we don't, we would still manage it with the same techniques. We would use pull requests to manage it just like we do www.jenkins.io, but it would be a separate site and a separate repository. Would that be okay for you or? I think that's fine Mark. Okay. Yeah. The idea would be, we would redirect the existing WordPress site to the new location so that we could switch off the hosting of the WordPress site. Okay. Yeah. I think the timeline for renewing the current site is around April. It's an annual subscription. So the subscription is up in April. Good. Okay. So then let's put this, Mark, to work with the infra team, infra team to confirm that we can host Jenkins is the way dot Jenkins.io in the Jenkins infra. And that would mean a GitHub repository, a site, and it could be on Netlify. Elsewhere, it doesn't have to be anything that we do an awful lot for. And then we'll coordinate it with Gavin Mogan. Thank you. Thank you. That's the piece that I wanted to check on. Okay. Great. I'll stick around. Okay. Great. Well, so that's excellent. And so then onto the next topic, she code Africa contributon. So Xenob, I apologize that I have not done my actions yet. Help me with the reminder on the timeline. Where are we at and what's the upcoming steps? And Xenob's baby may be keeping her busy. Hello. Hi Xenob. Yeah, sorry. Yeah. You're saying? I wanted a reminder on the timeline. I'm a little worried. I haven't submitted the project ideas yet. Okay. So if we could get them before the end of this month, if that's okay by you. Sure. All right. That's easy. Absolutely. So before end of February. And the funding, so the, so CloudBees funding has, I guess, Alyssa, it's a good question to you. Have we done the right eye dotting and tea truss crossing to assure that CloudBees funding has been submitted? So the last time I spoke with Jude is that legal was revealing the contract. Okay. Agreement. But we do have funding in place saved for this specific project. So I'm not worried about that yet. All right. Great. Excellent. CloudBees funding is approved internally at CloudBees. And just so you're clear, Zinov, it's actually in my budget as a manager. So it's where we like it. It's where it was the person who cares deeply about it. It has the one who has the funding. Yeah. So we're just working the details yet. Good. Okay. Still, so that's the thing that I needed since still need mentors and open to more project ideas. So I'll continue Mark to continue recruiting. So the project ideas post looks like this and offers program management, the inclusive naming initiative, screenshot updates and that when we really do have clear things and then test the tutorials and test automation. So all of those are viable. So Mark, you have a couple of names by there. So are those confirmed mentors? They are people who said that they were willing, yes, as part of the Docs office hours. So Meg mentored last year and is willing to do it again. Kristen mentored last year and Dheeraj has said he's willing to mentor this year. Because he's in India, it's a little more complicated getting time zones aligned between Dheeraj and Meg or between Dheeraj and Kristen, but I think it's still workable. Okay. I know that's great. I mean, you got mentors to project ideas. Yeah, we're still, it feels like we're still short-handed. In particular, last year we had some surprises where we had changes proposed, but no one to review the changes who had permission to merge them. And so it's a danger here that having mentors in this case is necessary, but not sufficient. We also have to have the right maintainers agree that they're willing to review the pull requests that come in to make the fixes. Okay. And then we had an additional project idea. I should note that from Gavin Mogan saying, hey, web browser automation is a very interesting field and doing screenshot updates with web browser automation might be something that could be done. So automate the taking of screenshots. Like that? Yeah, it's an interesting, but for me, that is to me a much more challenging programming task than many of the other tasks we put on the list. It's an intensely valuable programming task, but it's more challenging. Okay. So, Zinab, anything else that you wanted to highlight on Contributon? Oh, nothing else. Okay. So, and let's see, I had the link to the submission form someplace else in the notes. Here it is, good. Let me be sure that I copy that forward so that we've got it. Great, okay, so we'll get those in before end of the month. And we've got at least one more meeting of office hours to safety check that we did that on time. Good. All right. Okay, then the next story is news. Oops. And on the news front, we released Jenkins 2.335 released with more UI improvements. And the system base installer, Linux installer. And that's their bug reports are arriving for the UI improvements. A number of issues were found in terms of images that aren't quite right, et cetera. And bug reports are expected on the Linux installer. Then we've got Jenkins 2.332.1 is coming. That's the March 9, 2022 LTS release. And it will include UI improvements, what I'd call phase one, not the full set that are visible in 335, but an interesting subset with some really nice improvements, like plug-in manager, tables, it's a nice look. And that will need a change log and an upgrade guide. We'll do that as part of the docs office hours. Likely first review will be next week. Any questions on that one? No question for me. Okay. All right. Next topic was, this is more of a, how do we wanna do it question? And so Xenob, for you and Alyssa, this is a really good one for a check for the two of you. Gavin Mogan asked the question, hey, he would like a set of standard responses. You're having trouble running something inside Jenkins, but it works locally. And how do you solve that? And it's a very good question. We actually had a wiki page that specifically addressed that. The way it said it was, hey, my software builds on my computer, but not on Jenkins, why not? And this then lists a checklist of ideas of things that should be checked to understand why inside Jenkins it might fail, but outside Jenkins it would work. And Gavin has noted some additional spots. Now the question is, where should it be placed? So the idea I suggested to us, hey, here's this page, System Administration. And it's got a bunch of subtopics, backup, restore, monitoring, chef, puppet, logging, scripted, diagnosing errors and getting a thread dump, those kinds of things. My thought was, we should put another entry here at the same level as diagnosing errors and call it troubleshooting and then have a page that has those frequently asked questions or common concerns, hey, it doesn't do what I expected, why not? What do you think? Does that seem reasonable to you? Is there a better way that you would recommend? And so... So my thoughts are, instead of putting it on the System Administration, why not it be a whole different section on its own? So I don't have to, because I think troubleshooting is something that a lot of people have issues with and it's going to have a range of different topics when it comes to troubleshooting. And as time goes on, if it's something that keeps getting updated, it will get potentially very large with very different topics on how to troubleshoot, so I don't think it should be a bad idea if it's like a different section on its own, not on the different section for troubleshooting and Jenkins and on that section, you have these various different topics that you have to troubleshoot Jenkins. That's my own suggestion. I like that. Okay, so I think what you're saying is what we would do is in addition to a System Administration section we have now, we would add at this same level a troubleshooting section and admit that it would have subtopics and the subtopics might be troubleshooting how to do builds. Another might be troubleshooting port conflicts or troubleshooting. Yeah, so that might lobby that this, a copy of this diagnosing errors thing, or at least its information might go into that troubleshooting section as a dedicated troubleshooting section and obtaining a thread dump likewise is really a good, that's a good troubleshooting tool. Yeah, I like that. Okay, good, more attractive as a separate top level section as a separate section at the same level as System Administration. Move the, move content into it and extend and add content. So the idea would be things like, and I'm gonna copy those now, obtaining a thread dump, obtaining a thread dump. And the other one that we were using was diagnosing errors as an example. Good, yes, excellent idea. I don't know why I didn't think of that, very good. Okay, any other suggestions or insights to offer there? I don't have any, Mark. Okay, so this has a nice benefit as well. We would use a page redirect, those two existing pages to the new location. That's be part of the pull request, create the new section, redirect the existing pages to the new location and move the existing page content to the new location. Yeah, that's a good one because it's not just showing us, showing it a contributor, how do you do the new section? It's also, here's a new section, it needed to be populated with some existing content so that that content would redirect. Good, I like that. Okay, very good. So this redirect doesn't mean that we are still going to have this topic on that system at the new location section, but I'm not sure how the redirects will work. Yeah, so good question. So because this is a full level page, so diagnosing errors is a top level page, it would disappear from this table of contents entry here, so it wouldn't be visible here, but if someone now opened this URL, it would immediately redirect them to probable shooting slash the diagnosing dash errors. So like that, it would be as though they had typed the correct URL and that redirect then is a permanent thing and it's the Jenkins.io site is designed to do those redirects very easily. It's a simple file, has this particular name and then inside the content of the file it says it's a redirect and what the destination of the redirect is. Okay, because I was considering opening the PR with the new section, working on the PR with the new public section section, but I'm not sure how to go ahead with the direct path. Oh, well, so let me show you an example of a redirect so that you can see it. Let's do that because if you're interested in doing this, if you're interested in doing that pull request, that would be great. And let's show you how you do a redirect. Okay, so here's, I'm gonna bring up my thing to find a redirect. Perfect, here we go. Content slash account.adock. And so I'm gonna open that up and we'll put the URL in it. GitHub, Jenkins.io. So now we look at content, account. What was it? It was content slash account.adock. This one, perfect. This is the code for that file, that's all it is. And in fact, maybe we can find one that does a redirect into www.jenkins.io, let me look just a minute. Yes, here's an even better one. Okay, here's an even better one. All right, so this is one that Alyssa might remember. Here is an example of a, no, we won't do this with Alyssa, we'll do a different one. Okay, so how about here is a redirect. Content slash content, what silliness is that? Yeah, here's a good choice. All right, welcome.adock. So there is a, if I go to Jenkins.io, welcome. It shows it automatically, you saw that it flashed the page, said this content has moved to such and such. And so this is a good example of exactly that. And it shows how that works. So I'm just gonna put that into the notes here. So Zina, what you would do is you would copy the content of the existing pages into the new location in the directory structure. Then you would create the same file name as those existing pages and all that the same, that the existing page files would have in them is this very simple four lines. Now the redirect URL here is not slash, the redirect URL you'd need to provide is to docs, doc slash, we'd have to look it up, it's doc slash book slash troubleshooting slash diagnosing errors. Docs new, okay. Yeah, that would be an element. Docs new, okay. All right. So that would be the idea and then you do that. Okay. So does that feel comfortable to you? Yes, it does. But if I have any product questions, I'll just send it in the speech. Perfect, yes. Happy to help and happy to coach, absolutely. All right. Okay. Anything else that we need to discuss on the troubleshooting page then? I'll review this same concept in docs, office hours, Asia, about 12 hours from now, just to be sure. So I expect that they'll say, oh yeah, we like Zina's idea, let's go with it. Okay. Great, thank you. Okay. So we are at about half past. Zina, sometimes you've needed to leave at this point. Are we at a point where we should just call this stop and call our meeting done or do you want to watch as I go through a bug fix? I have to drop off now. Okay, then let's call the meeting done for today and we'll take these other issues later. Thanks everybody, great session. Thank you very much Zina, thanks Alyssa. Thank you Mark. All right. Bye Zina. Thank you Mark. Bye Mark.