 Welcome to Docs Office Hours, it's March 25th, 2022. This is the Asia edition. So agenda topics, we've got news, the Linux installer switch, a new addition to the improve a plugin task and that's it for today. The Sheikot Africa Contributon and the OpenPRs I'd propose we let ride for another week. Sounds good. All right, so item one or any other things we need to add to the agenda? It looks good to me. Okay, so 232.332.2. Yes, there are a lot of twos and threes in that version number. Release candidate build is available for testing. And yes, I volunteered the doc sig to write the a change log and upgrade guide plan to review asynchronously early next week. I don't have it written yet. It's pretty simple, several fixes, but not anything really substantial and no need for an upgrade guide. No need for any significant content in an upgrade guide. We do have an open issue with Jenkins.io updates. In the last 24 hours, we've not seen an update that's published all the way out. We think, I think it may be due to a change that was made to the content delivery network caching that we use, but the infra team will need to be investigated tomorrow. Then in terms of upcoming or kind of cool content, Basel Crow created a four page plus blog post on system D and it gives some background. Meg, you of all people will appreciate this. He goes all the way back to 1983 talking about the init process and the section eight of the UNIX man. I've been in the labs for three years. Then you wouldn't know how old I am. So then he talks about the enhancements that were made in Solaris and in Ubuntu Upstart to make things parallel startup possible for faster startup. Then system D arrives and by 2015, it's adopted in all the major Linux vendors. And now in 2022, we're using it. Wow. So yes, it's like a history trip down memory lane. Oh, and the W. Richard Stevens book is on my shelf. And if you read the early, the front pages of it, you'll find my name. See, like I said, the scars truly run deep here. That is, yeah. So Darren Pope used about that. Wow, I'd forgotten the UNIX network programming. What a great book. Excellent. Yeah, I sort of played Yenta for Stevens and the various people at SEO. And so he mentioned me. It makes me sound much more important than I was, but pretty cool to have your name in the book like that. Well, and that is an epically popular book. So justifiably so. So talks about the technical background, how Jenkins used to do it using some native C code to perform system process management, demon management, and now has switched to let the system do it. And then configuration changes. Darren and I did a, oh, there it is, UNIX network programming. Darren and I did a live stream today on the topic. And I think we're continuing to get a sort of low flow of arriving bug reports of various types. This is a change in code that's 10 years mature. And so, yes, it's no shock that there are some surprises. This will be posted tomorrow, assuming we can get the issue with updates resolved. I would say it's a credit to the quality of the code that there's only a few small problems. Yes, Bazel did an amazing job, particularly with almost 500 lines of born shell script. So yeah, it's terrifying the things he had to do in order to make it upgrade adequately. Wow. I never got to know him. I would have liked him, I think. Yeah, well, he came into his current role from a previous role where he did ZFS, so ZFS file system debugging. Okay. And Linux and FreeBSD kernel debugging and all sorts of interesting roles. So he's got a varied background from the rest of us who did all this Java code and never stared at an operating systems internals. Yeah. All right, so that's about it on that one. The managing a service page has been updated as well with Bazel's changes, part of the blog post also is to update this documentation page. Let's see if we can find it. I know it's in system admin, we said where it should go. This page has now been revised a little bit as well to talk about, hey, how do you do various things? Oh, marvelous. Okay. Any questions on the system five in it to system D change? No, that sounds some problems that we'd had simmering in the back of our minds really. Oh yeah. And there are several cool features hiding in it that users will be very pleased to use. Now we've got a new addition, thanks to Daniel Beck to the improve a plugin task list. Jenkins code QL scanning is now production. The beta has ended and it's ready for production use. And what this does, he's provided a description of it here with instructions on how to install it. I just ran through the instructions on a, one of the small plugins I maintain, it's revealed to follow these instructions. They work brilliantly, really great. Perfect. Hopefully that means that more people would be interested in knowing, oh, hey, this is easy. I can't adopt a plugin. Exactly. Well, and in this case, he gives you, he's got all sorts of guidance on, hey, this is advisory only, do not panic when you see it. You need to, and then he enumerates, this, the problem it's warning you about is a real problem if the following conditions are met and then he enumerates them for each type of issue. You must be doing this in order to have the problem. You must be doing this. You must be doing this because he warns, look, this thing is, it's an automaton and therefore it's prone to failure, right? It can't predict every case. So yeah, so it's a great story. And now, Kristen, I guess I did have a question for you on topic. Are you doing okay with the Google Summer of Code? Things working okay for you there. I've seen you give replies. Thanks very much for the replies. And it feels like people are making progress. Any concerns from you? Not really. I would, I think it's more, I would want to have more, I guess like student involvement maybe with this SIG or some of our, maybe they can pop in at our meeting if we ever, if that project ends up being one of the ones that's able to move forward. But like I would almost, I would see that being something that maybe we could take like every once in a while, have part of our meeting, they can come and drop us, drop and ask questions. I would hope that eventually, like as part of the meeting, the community, if again, I think if that, any documentation type projects are chosen, they could come and see our SIG and present at it. But we'll cross, like that's usually actually a good thing for any Google Summer of Code project is any, we are documentation. So they have anything to come stop and talk to us. But yeah, I don't really see too much. It's funny that every time we do these stuff, I'm just like, oh man, I want to start working on some of the stuff again too. So it's exciting, it's good to see interest. Yeah, do they, do we have good communication? I'm the, for the Sheikot Africa, we're very uncomfortable using the Jenkins SCSI. They wanted Slack. Do we have a, I mean, do we have a good published communication thing? Yes, yeah, that I, as I've never seen any Google Summer of Code person not be all up, like all into Gitter. Like, so that's actually really nice, is that we have a lot of Gitter action and it will probably be where a lot of that stuff happens anyway too, because that's kind of where they first maybe started working with Jenkins too. I don't know how the discourse is looking. I checked that every once in a while, but I don't know if it's maybe more useful. I feel like the Git project is using that a little bit more, Mark, I'm not entirely sure if that's an accurate statement or not, but I don't see it's not really as relevant for the questions that are coming in for any of the GSOC stuff. Well, so, and we are seeing positive results. So they've got community.jankins.io now has a mentor channel and that's good. That's healthy so that the mentors can talk to each other. It is still, it's publicly visible to everyone, but only writable by mentors. So we have to acknowledge we're posting publicly. We can't say terrible, horrible things. We're also using the community channel or the community to post links to the project plan drafts for review. And that seems to be working okay. We've received a few. Now, one of the things that we discussed in the office hours earlier today was what I'd call a brainstorming session. What I did was I realized that for the Git plugin idea, we hadn't yet talked about what the user experience would be. And so I spent a one hour session with three mentors and two of the candidates talking about, hey, what will the user experience be for this? I wondered, should we consider inviting the students to attend a doc's office hours maybe next week and say, hey, we're gonna do a brainstorming session on these docs related projects if they attend because we really are right now in Asia time zone or in Asia compatible time for them. Right. Question is, is it worth the extra prep work? We'd have to do to be ready for that kind of thing. For me, the prep work is at least a good hour or two of working on a document, thinking about it, identifying questions, et cetera. And I have almost no spare time at this point. I'm still buried in new job. Yeah, and that's what I'm feeling right now. I guess maybe what I'd propose is rather than next week, let's call it if needed in the future. Yes, that might be better. And let's watch and see. Great, because I think that we have to be a little careful about some of that because I think that part of the project proposals are they're supposed to come up with some ideas too. So I don't really want to end up doing the work for them. I really am excited to see what ideas, like fresh ideas that come and see just like kind of like a new perspective. And I kind of want to see like some of that too. I think that's a good point. Now what we could watch for is if we start seeing, we see some common theme that everybody's missing. Yeah. That makes sense to do. Right, yeah, like that. That's kind of, I would love to see that too, but it's definitely like eventually too, like they should stop by our sig meeting and be able to, especially if the project, they present it and talk about it and we can provide feedback and stuff. But yeah, it's like, I don't really know too much about what we want to design now, but I don't want to, I want there to be good, as I don't want to like, I was like Tarnish is kind of bad, but I don't want to maybe give them some ideas or something then they think they have to do it our way. Right. It's like, I want to see like, I'm kind of excited to see maybe a different, like their perspectives and kind of like incorporate it in and then we can review. And like, you know, oh, that's a great idea, like how you're laying it out. Like that's maybe not like what we would have thought to do, but oh, it makes sense. And then we can kind of like tweak it and work forward, but it's like, I kind of want to see that type of thought first before getting to it. Cause I don't, I don't want it to turn into something where it's like, oh, I have to do exactly what the mentors say. Sometimes we have to feel like Google Summerco, we have to be a little careful about this stuff like that. Cause it's, it's not just, you need to do exactly what we're telling you to do. I really want to see ideas. Right. And we, and when we, when we have to choose between the projects, I mean, those who've been able to think at that level or should those are the ones we most want to encourage. So. Right. Good. Okay. Very good insights. So we'll watch and see and let's go from there. If, if it turns out we need it, we can certainly always do it. Yes, that's true. It's not, we're not blocked from doing it by delaying and we're not in the period even yet where they can submit their application to Google. So we're still, I think it is a week or two away from when Google even opens it up for submissions. Right. All right. Any other topics before we close for today? After you stop the recording, I have one thing for you. Okay. Great. Then I'm going to go ahead and let's call it done. Thanks everybody. Thank you. Recording will be available in about, well in 24 to 48 hours.