 Welcome everyone, it's the 17th of February 2022. These are Jenkins documentation office hours. In Asia, it's actually the 18th. We'll go ahead, agenda topics I've got, news. Jenkins is the way content merge. Weekly change log review process discussion, just to be sure we're okay there. LTS change log for upcoming. A troubleshooting section proposal that came from Gavin Mogen and Xenob in today's earlier session had a refinement for it. Good first issues, if we have time, I thought we could go through and do a live bug fix so that others could see, hey, this is how you do a fix. And then if we've got time, discuss system five in it to system D and open PRs. Any other topics that need to be on the list? Nothing from my side. Good to me. And at the conclusion of this session, so after one hour, we will end here because then we begin a 30 minute session on Google Summer of Code for those who may be interested in Google Summer of Code. So it won't be on this call, but a different call and I'll be there and Alyssa Tong will be there. Great then. So let's talk to one item of news. 2.335 has been released. It now includes the system D-based Linux installer and a migration facility that migrates from the old installer to the new. We've had two different users who mistakenly thought they could perform upgrades in Linux by just changing the war file. And what they need to do is really run the installer or run the package manager upgrade. And so we'll probably put some documentation there about it. The UI improvements have been a little more brittle this time. If we look at the Jenkins download page for the weekly, what you'll see is quite a number of bugs that have been reported, mostly related to images that are not being rendered correctly in the new build. This is not a big deal. It doesn't break functionality, but it is distracting for the look and people are working to fix the issues throughout have been working since they started being reported. LTS is coming March 9th. And this one will have the first phase of UI improvements and change log and upgrade guide will be needed. I'd propose we plan to do a draft review next week during office hours that will be just after the delivery of the release candidates. Any questions on the news items? Yes, no question is just looking forward to review the draft to know more about it, the process. That's all. Well, and this one, this one because of the UI improvements mean that more effort will be needed in the draft, right? And I think we may even do a blog post because it's there are things in the new look that are I think are really great to highlight and leaving them only in the change log and the upgrade guide doesn't do them the justice that I think they deserve. It'll also be nice because going forward in the docs when we have to mention that this change is, it's nice to have a blog post we can link to. Right, right. Very good. All right, so. Good. So you're planning to publish the blog next week or some... No, no, the blog post would be likely the week, the same week as the release. So the week of March 9th. Okay, sounds good. I'm not ready to do a blog post without, well, in particular because there may be backports that yet arrive, the number of backports was larger this time than typical in part because UI improvements have a tendency to break things no matter what. All right, any other questions on the news? Okay, next topic then. Jenkins is the way is a site that's been used to collect stories from users. And those stories have been collected, gathered. We're ready now to bring them under the control of the Jenkins project itself. They've been being gathered by a separate company or contract with that separate company ends in April. And we'd like to not lose these. So what's been discussed is a proposal that was discussed with Alyssa Tong and agreed on and with the help of Gavin Mogan, there's been a transition that's converted these pages and all their content into a data-driven website so that we can manage it as code. And what Gavin had suggested was, hey, let's Gavin's the initial request was, let's put it all under www.jenkins.io, but we've realized that would double the size of the repository because there's an awful lot of content here. So what we've counterproposed is thanks to a suggestion from Oleg Nanashiv is let's use a different location. And so the proposal is Jenkins is the way dot Jenkins.io as a separate site under the Jenkins.io domain name and we'll put the stories there, it will have this look and feel and we won't have to pay the extra cost for the hosting. I like that, sounds good. Yeah. Hi, Kristen. Hi, how's it going? Good. Great. Your name didn't pop up there, I was surprised to hear you. Oh man. So Will, I've got the action item to work with the infra team to find the best and most effective way to host it. As an example, we're currently hosting wiki.jenkins.io as a Docker image in our Kubernetes cluster. But we could just as easily hosted other ways and I just have to learn from the infra team what they prefer. I've got a question. Are we gonna keep continuing gathering stories for Jenkins just the way? Absolutely. Okay, cool, great. What we probably will not have is we had a separate organization who was doing the curation and the coordination and we will probably switch this to instead use pull requests to coordinate it. And since pull requests should be lingua franca for all of us or everybody who's using Jenkins, I don't feel bad about that. Yeah. No, no, no. But that means we need a contributing.adoc file for the repo, right? And we'll need a team that reviews them. Yes, so let me make a note of the question because it's worth me double checking with Alyssa. We continue to accept contributions to Jenkins is the way and I think the answer is yes. Yes, but likely with pull requests. Anything else on the Jenkins is the way topic. I think on Gitter, there was a conversation between Kristen and Gavin where Kristen said that Mark, do you want to add it as a agenda to the meeting? So is this was the same thing or not? I'm just reminding. No, that's this thing right here. Okay. Yeah, I saw that. I was like, yes, we got it. Right. It was good. Thank you very much for doing that. Excellent, excellent question, Dheeraj. Well done. Okay, that's all. Good. Okay, yeah, so and that when I think is, we will have to get to that conversation. I think Xenob has made an even better proposal than I made. So let's get to that here soon. So next topic or anything else on Jenkins is the way. Okay, next topic then, weekly change log review process. So thanks in particular to Dheeraj, to others, if you've been involved in weekly change log review, the technique we switched to is asynchronous. And that makes it better for me and that I don't have to have two office hours during the week on different days, both late nights. So I appreciate your flexibility there. Is it working okay? It worked great for me last week. Dheeraj, did you feel like your concerns were resolved and honored or did I miss something? I think it's, it works great. My concern was just that I will not be able to look at the pull request multiple times during the day, during the week. So during Monday, I would just remember it like at a weird time that, oh, today I need to review it. So I'll just go to the bit of and look at the PR and just spend around half an hour, something like that. And I will just review it and be done for it. So it is easier for me as well. Okay, good. All right. Yeah. Now I have not, I have not sent any reminder emails and that was one that was listed on my to-dos. Would it help you if I sent reminders? Reminders of what? Reminders to others. Hey, please review this this week. I think it would be more useful is like, is there a deadline that we want to do that? There is. I need to, if I haven't seen them by Monday evening, six or seven PM, my time, I won't see them. Okay. So that, that maybe is something a little bit more to remember too. Cause yeah, just to know that I have a good time to review everything by, okay. Yeah. So before marks, let's call this end of day Monday and end of day Monday, my time, which means before Tuesday, about 7 AM India standard time. Or let's see, Kristin, in your world about 9 PM, your time 10 PM is getting to the point where I want to be done for the day after early morning. Yeah. No, I get it. I get it. I just more like, what time do I have to remember to make people to get on? I'm a late night person. So sometimes it's, you know, just like it comes to me later in the day. So I just want to make sure it gets feedback in before. So it actually helps. Yeah. And thank you very much. So I think I may try sending reminder emails on Sunday evening or early Monday morning, just in case. And we'll watch it and see if it helps. If it doesn't help, I stop sending them. But if it helps, great. We'll watch. Good idea. How will you send reminder emails to whom? I was just going to send them to you, to those who are in attendance at this meeting, because you've been the reviewers. So the candidates to be, ooh, that's a good point. The candidates to become, to become, what's the title again? How embarrassing. Copy editor? Copy editors, right. Receive the, receive the reminder. Yes. And we still don't have the contributor license agreement thing. So I'm holding off on having you submit a contributor license and therefore holding off on making a copy editor still. And Oleg's just been very busy with the other things and EZCLA registration hasn't happened yet. So he's still implementing it for Dynatrace too. Oh, okay, good. Yep. So what would this EZCLA registration process mean if it happens for us? So what, there's a contributor license agreement that is required in order to be, in order to be a copy editor. And that contributor license agreement is you agree that you'll live within the bounds of contributing to Jenkins. The challenge is today we have that process, but it's rather complicated and requires submitting signed PDF files with some exotic signing techniques that we really don't wanna put you through that. Okay, that makes sense. So it's just trying to avoid some work. Yes, we could make you go through the CLA process that I submitted, but it was, it required GPG signing of something and this and that. And it was really complicated. Then Oleg had me do the EZCLA process as a test and it took about three minutes. And so I was much happy with the EZCLA process. It's a lot more friendly to people who are contributing. That's great. So last question from my side is you're saying to, we need to complete it before your end of Monday. So it's like the previous docs, office hours, time. Yes, yes, that's a good threshold. If you get it done before the start of previous docs, office hours, that's good enough. Okay, that's all. Now, Meg, I love that you put in a question there and I think it's a good one that we need to ask Gavin. Let's go back to it. Will we have a search facility? I think we certainly want one. We will need to register it with Algolia. And they have two forms of search. I don't know which one Gavin will prefer. There's the really smart, finely tuned one that we use on plugins.jankins.io. And then there's the pure docs search which is the one we used on www.jankins.io. And that one has the benefit that we don't have to do any administration of it, any carrying or feeding of it, it just works. But it's not as well-aligned because when we tune something, it gets better and better based on the tuning. Right, and this, because this could be interesting. Why does anybody want to look at this site? And they might be looking for somebody who's doing something similar to what they are so that could get into really interesting sorts of searches. Search is a really, we've seen that the search on www.jankins.io is very helpful and that the search on plugins.jankins.io has actually guided us on which plugins are most in need of documentation. It's actually a little embarrassing that the top hit plugin is still the Git plugin after like 12 months at the top of the list. So there is no hesitation to spend effort on documenting the Git plugin. Anything we can do to help it is good. All right, anything else on Jenkins is the way. Okay, next topic then. Oh, we talked about, what am I saying? I went back too far. Weekly change log, anything else there? Nope. Okay, LTS change log. So this one, the Backport candidates are in process. We'll start, we should plan to review it for next week. And so review at next office hours or before next office hours. If we're lucky, I'll have submitted a draft as a pull request and we can talk it through, look at different ways to present its concepts, et cetera. Any questions there? So would it be like that long change log that I see sometimes? Yes, yeah, it will. So it will look like, let's take a quick look at it and see it will look like this. If we go to the change log, it will have this style of look. So two sections, changes since, changes since 2.332 and then notable changes since 2.319.3. Is that what you were referring to, Dheeraj or something different? Yes, the same thing. We also discussed about this during one of our previous dog office meeting where you explained it to me with the help of diagrams. So yes, that would be helpful if we review it. Great. Yeah, and deeply valuable, much appreciated that you're willing to review it. We will also do an upgrade guide and the upgrade guide will follow the usual pattern of a number of things that have to be noted in it because they are actual upgrade relevant changes. And there are some things that may require migration or plug in compatibility concerns that have to be noted in the upgrade guide. Yes, sure. Great. All right. Anything else on LTS change log? Okay, next topic then, a troubleshooting section. So Gavin Mogan asked a question in Gitter or observed, hey, we're seeing a frequent question that's happening is of the form, I could do this operation from my command line but it fails in Jenkins. Help me fix it. And for instance, things like selenium tests or operating system user specific tests or path specific conditions where, hey, you had the wrong Java in the path, those kinds of things. You can imagine there's almost as many of these kinds of failures as there are people in the world. So what he suggested was, could we have a troubleshooting section or what he suggested was he wants a page to put these kinds of things. And in Gitter, I had suggested, well, let's put a troubleshooting page underneath the system administration page. And in reviewing it today in Docs Office Hours, Europe time, Zenab suggested, hey, why don't we just create an entire troubleshooting section like, and here, let's take a look at it and showing show you what her idea was. She said, let's do this, oops, wrong one. Let's go here. And if we look at the overview, you see system administration managing and she's suggesting after scaling Jenkins, let's put troubleshooting. And in it, we will immediately put obtaining a thread dump and diagnosing errors because they both really are about troubleshooting. We probably should also consider putting viewing logs under troubleshooting. Yes. So the idea was there will be a new top level chapter, if you will, in the handbook. What do you think? Does that sound okay? I love it. Could I add one more other thing? Any of these that we can reproduce here, like we can do the stupidity, if we could show a log snippet about what it looks like when it fails. Agreed. That would be a nice thing to include. And it might also mean that search would mean, if I'm getting a certain error message, I could search for that error text and land in the right spot. Okay, no, I'm not sure. So you're suggesting for any of these common questions, if it's got a failure mode, we describe it? Well, what I'm saying is when I do this wrong thing, does something show up in the logs? Got it. And if it does, what does it look like? And I would prefer if we could put in the text rather than a screenshot of the log because then the text would be searchable. Makes sense. That makes, okay, I see what you're saying. So by including the text rather than just a picture, we get the benefit of searchability. And yeah, I like that. And it should work because it should be straight ASCII text, so. Right, yeah. And I know, I mean, we've got all over the place, we're like, watch your logs, look for your logs. And we never tell them what they're looking for. Right, good hint, okay. Exactly. So when we are searching for the error message, I mean, with the error message, we, instead of stack overflow, we can land to the Jenkins site as well. Right, right. Right, right. And I think it's interesting, so as long as it's a top level after system administration, because I can imagine that some of these problems are people using Jenkins. Right. And then other things are people who are system admins trying to set up at Jenkins. And that's almost too completely, I still want to keep. System admins whose users are coming to them and say why this is happening. Right, right, exactly. So it's like, I would rather have it at like a top level. And I don't know if we need to further break things down, but I think starting off with immediately like, maybe it was in the form of a question, like this is Selenium is, like you're saying Selenium is broken or my job is wrong. Or I think I saw one even in the chat today about the Jenkins home was set to a different thing. And it might not have really, but that's an example of like system admin stuff, but maybe you think, you know, it's a little bit different than being able to. But the thing is, those are the solutions. Right. If I knew that I have the wrong Java in my path, I could fix it. I'm seeing some other error condition and I have no, you know, and the answer is you've got the wrong. So that's, yeah. Okay, I see what you're saying, Meg. Right. Well, and so, and I think I love those ideas. I was going to bring, let's see, where's the sample? Here it is. So as an example, we have some answers already. I'll just put them into the notes. And Xenop has agreed, she wants to be the one to do the pull request for this. So she's asked if, hey, could I do this? And I described to her, hey, here are the steps you take. And this is how we would do it. And she was very happy to do that as a contribution from her. I was getting a feeling that she was starting to get restless that she's managing all this stuff. And it's like, I'm not getting my fingers into this. Exactly. I want to do something. Yeah, right. And she is absolutely fabulous. I just love her. Okay, so the thing that I wanted to show briefly here was this wiki page that already has some of these kind of things. Admittedly, it's not a pretty page, but it gives us several failure modes with error messages. And so it's the pattern, and notice the date stamp on it. It was all the way, it was started originally 10 years ago. So this is not the first time we've seen this kind of problem. Right. Okay, so we will use an entirely separate section, a separate section in the user guide and we've got now, I think, I like that that we had a third candidate, which was viewing logs that should move into there as well. Yes, exactly. Okay, so, and that is, where is that? This one right here. And so I was guiding Xenob in the session earlier today on how to use a redirect for those existing pages so that the page can move out of this chapter and still be found by its old URL. And she, I think she understood that as well. And if she didn't, we'll make it work later. Anything else? Here's how you test, Chris, the redirect. Oh yeah, yes, absolutely. Testing, testing, testing. Anything else on the troubleshooting section? Kristen, you were the one who brought this. Is that okay for you as a proposal? Yeah, that works for me. I originally started looking at the community forum because I didn't know if there would be a good place to put it there. I like it on the Jenkins IO because that way it's a little bit more, if it feels a little bit more official than like Daraa was just saying about like someone Googling a stack of a flow for her answer that could be out of date. We will have to make sure that we keep these, we add these to reviewing. However, we will make sure we do updates to make sure that the troubleshooting section stays accurate. You've... Oh, sorry. Good question. And I wonder if there's like a good way that we can figure out maybe, like after we set it up, if there's a good way to maybe put a call out on some other forums or anything to see if we can get ideas for, hey, what are some other places that we run into? Oh yeah, yeah. And make it clear that there's two ways, obviously we would love to have PRs against this when it happens, but tell them if they have an issue and they don't know how, I mean, they may see the problem and they don't know the answer that they can file an issue. Right. Yeah, well, and you Kristen, you're inspired to, there's a page that doesn't exist yet that only exists in community.jankins.io. There's tables to bives, migration steps. It's a pretty common report. Hey, I was running Jenkins 2.173 and I've decided to upgrade to 335. Oh my goodness. And I'm broken. Yeah, it's okay. How do I do that? That was three years ago we shipped that. It hasn't been maintained for three years. And the answer there is, ah, we'll do these steps as a minimum. You must do these things. And we've captured them by hard experience, but having them on an official page, I think we'll do a better job for us of, yes, here's the hard experiences page. Great. Great, okay. That's so funny. I can't believe that's the, maybe someone finally, oh, we probably should upgrade. It's like, oh. All those security advisories. Wow, maybe one of them applies. I bet a lot of people, they'll get hired in as they look for somebody that knows Jenkins and they go out that. Oh, sure. Oh, no. Exactly, exactly. Like an, oh no. I admit, I've been working with computers for a long time and I have never ever upgraded software without losing something I loved. Sure. And so I am the world's worst and I put off, Greg, I hate to upgrade software. I just hate it. Yeah. Makes sense. Well, and it's a fair choice, right? Hey, if it works, why should I break it? Why should I risk breaking it? Yes, that's the big thing, especially if you're shipping some very critical of your software here. Exactly. What's the statistic that 53% of the Jenkins builds being run are still in freestyle? No, no, thankfully, we have passed the tipping point. We've got more than half. More than half of the pipeline. All right. Woohoo. That's right. So more than half, but still there's still a lot of freestyle projects in this world. All right. Anything else on the troubleshooting section? Yes. So since Kristen also said that this troubleshooting section will help us to put our position in, like the near stack overflow when user is searching for the error message. I was wondering like, is this the only place for troubleshooting we have in Jenkins.io or there are other sections as well where there are other messages and there are solutions in form of log posts or maybe a dedicated section. My main intention is, I was wondering like, it's a very big idea. I was wondering like, can we increase the visibility of Jenkins or like whenever a user is searching for Jenkins related messages. So like before stack overflow, they would be thinking like, hey, I should first of all look at this search result on Jenkins.io because that's where the error is. So I know it's a big, big thing, but just wanted to know what you think. Yeah, good. I think it would be a great goal. Some day rank higher than stack overflow. Which is like very difficult, I know. Well, there's a stretch goal. Yes. I like that. I think it's- Well, we know how many hits this page gets. We don't track in hits for pages of documentation. Actually, I think we do track. I believe we've got, I think we've got page use data. Okay. And certainly Google keeps, do they? Yeah, I'd have to explore it to see. I haven't, I haven't much worried about our page rank for those kinds of things, just assuming that we've got a lot of content you have to create. Right. I just want to make sure that it stays up to date. That's kind of my thing too, like making sure that the troubleshooting is accurate. That's always a hard thing. But as long as we have a review to it every once in a while, like the upgrade guides and stuff, I think that would be enough. Yeah, maintenance of these stocks as a whole, for sure. Okay. Yes, sounds good. Anything else on troubleshooting section? No, I don't think so. Okay. All right, next topic then was, there was a new good first issue that was submitted today by Vodek on a report for broken, and I think it actually may be broken images. So if we look at this page, this is the bug report, but you see here that the configured global security thing that I think was a diagram previously is now broken. And so my thought was, we could spend a few minutes doing a live, let's diagnose this thing, or we could shift and go on to other topics. What's your preference? I'm good with fixing it. Does anybody else has anything more exciting? I'm sorry, what's the question? So the question was, should we spend the time to, as a group, fix this bug? It's a good first issue, or would we rather do other topics and let somebody pick it up later as a good first issue to work on? Except, wait a second, I have a protest. Oh, what's that? I think this is largely addressed in the PR from hell that I created in October that we still can't get approved for merge. Well, so that's a good test. And I think that's a good test for us as a group. Let's check it, because let's look at the one that you had created. That was this one, right? Security for no reference. It's the big one of security restructure or something. Restructure security section. Yeah. Okay, so let's open up that one and let's go look at its site preview and see if it has the same problem. Because if this fixes it, then we don't have to, whoops, wrong steps. Hang on just a minute. If this fixes it, then we don't have to do what we should focus on is getting this merged and let that fix it as well. Great. Okay, so here's the preview. Because I made big changes recently because of this very feature. So here is the page that he noted sophisticated administrators can use the built-in access. So this is customizing rules. I've got to find that page in the URLs. So Jenkins customizing rules. Oh, nope, nope, I missed it. It's right here. Yeah. Okay, it's on this page, which is controller isolation. So we borrow this URL, go back to the prototype site. Here it is, good. Okay, so go to the previous site. Still broken. Okay, good. So fixing this would still be needed even in this case. Okay. Except that the stuff that needs to be fixed is completely moved. Well, so then how about we fix it in your PRMEG rather than fixing it in some other location? Let's fix it there and use that as a motivation to say, this is one more reason why this PR needs to be reviewed and merged. Right. We keep it in ugly. Daniel observed here that he thinks there may be other cases where the same problem occurs. So we've got more than just a single problem potentially. So would you be changing stuff? Yeah, no, you want to grab it and do it or you want me to do it? Actually, I think it may be best if we have you. Well, we can have you do it or I think we could do the investigation as a team here. And then you'll have to actually be the one who submits the change. So we can have you submit the correction. Okay. Well, let's look at it quickly and then maybe I'll take it out. Go get that branch and get it up. Okay. Now to confuse you all, but for good reasons, we want to, okay, I did not touch this particular section. It's the link to it and security that I was in. Great. So this is a safe thing to change in your pull requests. Right. Or this could be separate than maybe I was seeing it as something else. What I had done, we used to have, we did it one point along the way, we had a separate file that was about the, enabling the agent controller. And that file went away because that option went off the UI. So it is now buried in the section about distributed builds. At the end it says that this, you know, this is something that happens and then it points to. Okay. Well, and if as I look at the files that are changed in your pull request, it looks like this file, this agent to controller file is not changed in your pull request. So I think it's independent. So we could make the change independently. Right. I was, yeah, I changed, I changed the one that was in the security section. I didn't, I left that same link. So. Yeah. So maybe that gives us now the freedom. We don't actually have to do it in your pull request. We can do it elsewhere as an independent thing. Let's. Since I haven't, I stopped looking at this all the time. I've just lost hope that it's ever going to move. Could we look at the preview for distributed builds? Preview for distributed builds. Which, okay. In this PR. Sure. So you want to look at, just let me get back there. Okay. You want to look at this one and you say distributed builds. Yes. Okay. Come on. Okay. So that's. It's, it's, it's, it's, oh God. He's got it. Our job's execute. No, it's. What controller isolation. Controller isolation. That's the term. Okay. So here's controller isolation. And zip down to the bottom. Okay. As it's. And that's all about how agents and all this sort of stuff. And. Okay, we're at the end here. There we go. And. Yeah. You're in the section. I think there's a header up just above where you are. Agent and controller security this one. Yes. Or agent to controller security. Okay. Yeah. And let's see. So this should have a link to the, because and just, but if you can't turn the filter off anymore, there can tweak the rules. This should be the link. Then you could tweak the rules. One 12 starting line one 12. You can tweak the filters rules by adding a loud and I rules to specify the commands, blah, blah, blah, blah. C. So now is that the bad link? Oh no, no, this is definitely not the bad link. Okay. No. In fact, the bad link is in a file named, let's see what did we just do is the file is named agent dash to dash controller.a doc. So, so that file is not even in your pull request. I think my pull request deletes that file. Well, I would have expected it to report that in the query that I did. Okay. And the reason it was because at one point I was making this. So if you looked at the table of contents here, you would find everything that was on the UI. And this is no longer on the UI because you cannot disable it from the UI anymore. Yeah. And well, so I don't, I don't see it there. I see securing Jenkins was deleted, but I don't see any other deletions here in this PR. In this PR. Oh, Lord. And it's, I'm pretty sure that that file got deleted, but the content is where I showed you. That's why I, that's, hmm. Okay. So I'm gonna, I'm gonna switch tools just for a minute so that I can, so I can run with the tools that are a little more familiar to me. Cool. Okay. So, and the PR is 4612. So, and you were thinking that it, that there may have been a change related to that agent dash two dash controller, this thing. That file I believe is deleted. Yeah. So that should show up in the diffs here. Okay. So there's a link to it that is unmodified. So I'm pretty sure it can't have been deleted and there's a link to it that's been added. So I think we're safe to go touch that file. Okay. Well, we can check that. We can always go back and get it later. We can do that, right? Right. I'm sorry, this has been going on for so long and my head is just foggy about it. Okay. So here's the file that is, that had that contains the thing that's broken and sorry for the tiny text, everybody. And then the place that was broken, it says for an introduction about the agent. And, oh, look, it's the picture. That's the problem. Ah. Okay. The problem is a reference to a picture. And now the question is, where is that picture and how do we get to it? So I'm used to having to do things like put one more double dot until we finally find it. So just a minute, I'm gonna start a build with this thing and we'll go, we'll play experiments. Okay. I'm trying to get back to that branch. Okay. So here we are. And let's open it up. Oh, and by the way, others have shown how you can do this exact kind of thing using Gitpod so you don't even have to run it on your own computer. Hi. Didn't, oh, it's still working. Okay. Sorry. My build is slower than I expected. Yeah. John Mark Mason showed how to do development on Jenkins.io using Gitpod so that you don't have to have a local workspace at all. Well, that's a problem. I broke something. Nope. Something's broken here. So I've gotta go fix a problem. Sorry that I have failed to show how to fix this particular bug. But we think, but I think the answer is we have to figure out where this picture is actually located and how to reference it correctly. So do that separately. Wait a minute, cause what picture? Cause the picture, as I recall, the picture that's in there is a tiny little screenshot of the thing on the screen where you disabled this thing. And that would be quite believable. And so what do you get? No. So back, what did Vodic say that that thing should go away? No, he just says fix it. So the picture is visible. And what Daniel's observation is that there may be other pictures that have a similar problem. So we need to look for other pictures in this securing Jenkins section that may similarly be broken because somehow their picture has been, okay, that one's okay. That's good. But there may be other things that have been damaged in the same way. And we need to just cross-check each of these pages to be sure. All right, so I'd propose we admit that that didn't work the way I'd hoped it would. We'll do that kind of thing later and call this one, try again later, Mark. Okay, yeah. And I really wish we could get that thing merged before we make any more changes to the security section. This is getting absurd. Right. I know, like, what else do we need for that? So I think it feels like we're... The crucial thing is we need... We need Daniel's blessing. Yeah, we need review from Daniel or Vodic and really Daniel's the right choice to do that. He had started it. We just need him to get time enough to do it again. Yeah. And because it's not, we want, you know, make sure there's nothing bad in it. It was like, at this point, like, could we just tell him maybe, like, it's just, this is past number one and we can come back and it doesn't have to be absolutely perfect. Right. The general point of this was to get the doc... Well, to add some stuff, but to get the doc structured so it would be easy to make small changes to it. They were a total mess. Right, right. And he was having that problem that when he needed to change something, so that was sort of the main goal here. And now it's just getting, you know, after months and months, I'm losing it. Okay. Yeah, so... Because I think that feature, maybe in this next LTS, the removing the ability to disable that filter from the UI is not in an LTS yet. I have a to-do note that when it gets into the LTS, we have to tell what LTS it's in. Right now it tells what weekly it's in. Yeah, and I think we can already predict that. I think we already know it won't be in, it will be removed in the March 9th LTS. Quite possibly, but that's what I'm saying is, so this is active, you know. Right. It's another reason to get that merge. Yeah. Great. Some of the other smaller PRs that are dependent on this one have some real problems that are non-trivial. They probably should, a couple of them might be done, I don't know, but this one needs to get in there. Okay. Yeah. All right. Anything else on that good first issue effort? Okay, next topic then. Linux installer switch from system five to in it to system D. I'm gonna do a blog post. There were many open issues that were resolved in the Linux installers as a result of this improvement. Special thanks to Basil Crow for a complete rewrite of the Linux installers to use modern Linux initialization system. The fabulous. It really is, it's an amazing what he did and how much he did. We now run automated tests on 10 plus Linux platforms to be sure that the installer works and yeah, it's a sweet piece of work. He did almost 500 lines of Debian SH script in order to, in order to do the migration. Terrifying. And that's it for me. I'd propose call it done. I need to take a few minutes break so that I can get ready for the next meeting Google Summer of Code. That makes sense. I need to get to dog school. For all the good it does. Dheeraj, anything else from you? No, nothing from my side as well. So Hisha, did you get anything worthwhile out of this meeting? Will you come back? You're muted if you're speaking. That's what I did, right? Yes, sir. I, it worked for you. Did the session help you? Said yeah. Yes, sir. Great. All right. Good. Thanks everybody. Everybody have a great week. We'll talk next week. Talk to you next week. Bye. Sure. Bye. Bye y'all. Bye.