 Welcome everyone, it's Google season of Docs Office Hours, the 2nd of November 2020. So Zina, I've got pull requests, blog posts, PR, and next steps as topics on the agenda. What would you like to put on the agenda? The updates I have. Okay, I'd like to talk about running, make run on Windows. So in the last meeting we had, you suggested cloning the repository on Linux, I did that, but I still encountered an error. And okay, good. So that feels like a good agenda topic. Any other topics you'd like to add on the agenda? And also, there's some comments on the PR, all that dropped some comments on the blog posts PR and the Jenkins operator PR. So I'll look into them before, I'll work on them before the next meeting. You said there are also on Jenkins operator? Yes. Any other topics? Or from Kristen or from Marky? Yeah, couldn't unmute fast enough. I have nothing. Okay. All right, then let's go ahead and we'll just run the agenda then pull requests. So we've got the skeleton PR, which I assume is the one that yes, Oleg merged this last week. Sorry that we hadn't merged it sooner, but that's great. And so it's in and ready to ready to fill in with pieces and the PR for Jenkins operator. I believe it's still in progress. Kristen, you've done some review on it and made comments. We've got comments also from the above and from Marky, good. So what I would like Zinab, if it's possible, once this PR is ready to go, like everybody has said that they approve it and everything, I would like if you could squash commit to bring all of these commits down into one. And that can sometimes be a little difficult, but if you need help, please let me know. I will be more than happy to help you do that. Essentially, go ahead. There is a, the label squash merge me has been applied. And so the person who merges it can just do that squash directly. Beautiful. So the Zinab doesn't have to Zina by assume you're okay if we squash merge it. That will collapse all the commits into a single commit. And then, so this is a don't forget to squash merge. Marky, you've got merge permission on that repository. I've got merge permission. I know Oleg has merged permission. Kristen, do you have merge permission to the Jenkins.io site? Probably not. If it's not immediately apparent to you, probably not. So just, we just have to remember that the label is going to apply. Now we need to honor the label and actually do the squash merge that avoids you having to do it. And it lets you still Zina continue this pattern of small commits that you use. I like that pattern. It's very healthy. Thank you. Okay. Anything else on those pull requests or are there other pull requests that should be in the list? Yeah, I see three. So I think we didn't. So, okay, yes. Oh, sample the ammo files, right? Well, yes. And there the, there was a recommendation from, from Tim, Tim Jacome, right? I wasn't quite sure what to do with his recommendation. So, Zina, do you have some concept of how you, what we might do there? I didn't, it wasn't clear to me. His suggestion was suggested that the authoritative repository was a better choice that the, the upstream helped me understand that. Okay. If I can find his comments on inside. So I think his comments had something to do with maintenance. Right. But it wasn't in this right, it was updating. Yes, it's on Jenkins operator. Okay. So it was somewhere in here. Oh, here we go. So his concern was this, to make that big enough to actually read. So do I understand his concern correctly that he's worried that by using the, oh, go ahead. So I think his worry is by putting this file in the Jenkins.io repository, no one is going to maintain it when it gets updated on the official repository. It's going to probably be, it's going to be probably difficult to track changes to the official repository if we replace the file here. Is it possible, and I'm just thinking out loud here, is it Zina, but this is going in the official repository, correct? As well as in the document. No, this is only in the documentation. Oh, okay. I see. So, you know, in this snippet here, I was using the file from the official repository. But Oleg mentioned that it might be a problem if the master branch of the official repository is renamed. So I suggested probably replicating the file and putting it on Jenkins.io. So we can have control over, more control over that. But Simija is raising the suggestion that if we should do that, that if we should replicate the file on Jenkins.io, we might not be able to track, properly track changes to the file on the official repository. So if, say, for instance, they make changes to the file in the official repository, we might not know immediately to update the one we have on Jenkins.io. Thank you for clarifying that. That's a lot more clear to me. I could, I agree with that. However, I would wonder if it would be possible to put a comment on the official repository that there is some linkage to this document. And if there's any changes made there, they would need to also be reflected in here. That way the person that we're making the changes would know that. And that's just a possible thinking out loud suggestion. So this is the repository that is the authoritative repository, right? So yeah, there's actually even more now that it's all coming back to me, to my fuzzy mind, to my COVID brain, as I call it. So, but Zina, what you did was you referenced exactly deploy CRDs Jenkins. So deploy CRDs Jenkins. And I don't see that as a. Oh, it does it. I'm not sure how it does this. You've got a command to resolve it. Yes, yes, that will resolve it. There's a hidden link in GitHub that you're able to use, the get buster hidden links, where you can pull down the raw content of that. But my concern now, now I understand what Oleg and Tim are saying. And because of this repo in particular, I would be, yeah, this is sort of a catchy one right here. Can you go, Mark, can you go back to the full request? Is there it would it be better to try to, like, version this? Like, is there, I don't know if the Jenkins or sorry, if the Jenkins operator is going to have, you know, versions? I was like, maybe that would be easier, instead of pointing to. I think the, I think Tim's concern is specifically to the operator and whom control. I don't want to use the word controls, the operator code base. There's like a big, there's a big thing sort of happening with people getting in and being able to become maintainers of this. What I would suggest, and this is a more official suggestion, is Xenop, I would leave line 593 as is, but I would add a comment in there that this is subject to change and it's best to verify like the repo to be safe. I mean, what do you think, Mark? That sounds okay to me. I'm actually a little concerned that I think that this link right now is actually broken. And so I think it's going to need to be revised anyway. And I don't know when the change was applied that caused it to become broken. Because it's not that these files have changed recently, but at least I was expecting that when I opened this URL in a web browser page that it would not 404. Yeah, you would actually get the raw. So that link is broken. So Xenop, that has to be corrected. And while you're correcting that, I would, I would add a comment in there for in that 593. I would add a comment that's basically says, this repo is subject to change or this link is subject to change. And it would be best to verify. That would be my recommendation. Would this be another good instance of something that we would have? Like, because I know that for the Getting Started guide, we have our place inside of Jenkins IO with a whole bunch of, say, like in the files because when people, you know, people don't copy. Would it be having something like a copy of this file or something in case of problems? I've seen people do that. I think the only, I think, I've seen people do that, but I've also seen it become problematic because there's multiple places to update and somebody forgets that one special place. Yeah, that's the one thing I hate, but I was like, just in case. Yeah. I'm like, wait, you didn't tell me about that third special place? You only gave me the first one. I just think it would be good just to make a comment in the code that this link is subject to change based on maintainers. Okay. Okay. Yeah, so Tim's phrasing here apply these official deploy instructions in the official repo. Yeah, so I think Tim's actually objecting to the idea of putting examples in this repo if they're conceptually too close to the production, to the real examples or the data in the repository. So I think he's buying us towards not placing examples in the repo unless they are somehow trivial or completely disjoint. Am I misreading his comment? I think this has, so just for the record of why this may be a bit of a, I think what I think Tim is bringing up and also Oleg is the maintainers of this repo in particular. There's been some, there's been, people have raised not being able to become maintainers of this specifically Red Hat. And I think what the fear is is that something will change in this we will not know or have any way to affect correcting something. And we're kind of at the mercy of the maintainers of this operator. And I think that's what Tim is trying to avoid as well as Oleg. I could be completely wrong. So I'm not speaking that they've actually told me that I'm speaking just sort of guessing but knowing some of the history with this particular repository. Thanks for the insights. So then do we have, it feels like what we're recommending then is that Xenob stays with a reference to the authoritative repository and corrects this URL. Is that okay with using now? Yes, yes. Okay, because I think that would address Tim's concern. It doesn't really address the concern that started us down this path from Pristin and I think from Oleg that, hey, we need a place to put examples that are bigger than will comfortably fit in line in the documentation. Yeah, cutting and pasting. I like Kristen's example from a week ago. Cutting and pasting more than a page of text is problematic and error prone. Okay, great. I just think one more thing that just should be captured is to, oh, you actually did capture it, Mark. Thank you. And include a comment warning that this will need to be confirmed. It works periodically. Yeah, I would just look around those lines, Xenob. Okay. All right. Has that settled that question then that we've addressed the sample we have on? Yes, yes. Okay. Discuss and include it. Okay, all right. So, running make run on Windows to see the Jenkins IO site. Xenob, help us understand for you. So, I was able to clone the repository and I tried running make one. I was getting a different error from the previous one. I've not been able to access my PC. Once I'm able to do that, I'll copy the error and send it on GitHub so we can discuss it there before the next meeting. You're running Windows 10, right? But you're running Windows 10 and WSL one. Not WSL two. Okay. Yes. And I apologize. I still have the action item. Oh, oops, wrong window. I still have the action item. Right, Windows 10 and WSL one. My primary work station is now WSL two, but I think I've got an older computer that's still got WSL one on it. Anything else? Not the post. Next topic then with the blog post and oh, that's the, we've got the PR for the blog post as well, right? And it is here. And Xenob, I assume that you're okay if we post this anytime, right? So you're okay if I adjust the date on this and if you're to post it today or tomorrow, you'd be all right with that. Yes. My apologies that I'm behind schedule. I didn't, I did not get married last weekend and still I'm behind schedule. One of the things that we've been taking as a specific action for our blog posts to increase their impact is that we're creating a social media post for them. So a Twitter, Twitter tweet and a LinkedIn. If you've got content you would like to recommend to be in the tweet, you're welcome to submit it. You'll see those in the social media channel in the advocacy and outreach channel on Gitter. Anything else on the blog post? Nothing else. Okay, next step. So we are now, it's, we're now two November and we've got until I believe five December. So we've got about a month remaining. You want to share with us some of the things you envision happening, Zinaab and? So once I'm done with all the changes on these TPRs, I want to start working on administering and extensions of the images. So yes, so I want to see if I can cover that and also cover something on cloud also before then. Excellent. Oh, and I wanted to show you something actually while we're here because I just merged something last week. Jenkins on IBM cloud tutorial is now merged and it's with Kubernetes. So your timing is great. We've got something to leave there. And this came from I think someone that's a contractor to IBM or something like that. But here's this page with screenshots of how you do a provisioning on IBM cloud using Jenkins. So your timing to want to do public cloud is really great. We also have on the downloads page of this thing, which is links to documentation from vendors on their public cloud deployment techniques. And almost all of them are in fact, Kubernetes. Google, IBM are both absolutely Kubernetes. I don't recall on AWS and Azure. That's excellent, you know, anything else that you'd like to share though, those already feel like large undertakings and interesting challenges. Now we'll administering, for instance, include how to deal with configuration as code in a Kubernetes environment. What sorts of things are you envisioning there? Yes. Configuration and code scaling, Jenkins on Kubernetes. I don't have my notes with me right now. I'm actually using my mobile phone. I've not been able to access my laptop. Well, and thank you for joining us from your mobile phone. That's impressive. Well done. Thank you. All right, any other topics we need to cover today? Nothing for me. All right, thanks everybody. I will post the recording. Thanks very much.