 All right, welcome. It's the 24th of May at 25th of May at 2am UTC. This is Jenkins documentation office hours reminder that we abide by the Jenkins code of conduct. Be nice to each other. And thanks for being here everyone. So topics that I had on the agenda included. Let's see. I'm going to bring out share my screen and we'll look at it together. Okay, so sharing screen now. All right, so you should see a thing titled weekly release change log, helping, etc. We see it. Okay, great. All right, Meg. So topics that were on my mind generating the change log for Jenkins weekly releases. This is an area where I need help where it would be a real benefit for us to have multiple people able to do this. And so my thought was let's use today's session as a working session. And what I would like to do is go through it once myself and then have either dirage or Meg go through it to see, okay, can somebody else do the same thing so that we're confident others can do this. Then we would do something similar in next week's meeting and have whoever that person is be the one who actually submits the change log. Well, and I would love to do it, but I am absolutely buried. Okay, so then you're not a candidate and that's, that's okay we're open to and if nobody's a candidate I still want to record it so that I can share it with others and say hey, here's a here's an opportunity. Because I think we can do this during this meeting and get it completely done. So it's, it's, it's a small thing and relatively straightforward. And how we do it is the more important thing than the precise details of what we're doing. Yeah. Okay, so then I've got a marks news topic on my kidney donation that's coming up and ways that people can help. Dear Roger were there any topics you wanted to add to the agenda. I'm not specifically today because I'm more interested to know about how I can help you. So that's why I joined. All right, great. Okay, well so then make any topics that you want to add. Nope, this looks good. Okay, so then let's, let's get started on this one and dirage, are you based on a Linux development environment windows or macOS Linux. Okay, good. So this will be, this will be second nature to you and it works. It works. That's the natural way that I do it so this should be a perfect thing. I propose are you interested in doing being the changelog generator, at least one of potentially many Okay, first of all, tell me what it is actually. I sure can you bet so the, the Jenkins changelog is that's a very good lead in excellent question. The Jenkins changelog is this on the download page we have a link here which talks about what the content is of each week's weekly release. And this changelog is what is, is the, the data that we will create today is what generates this web page. So it talks about how in Jenkins to 293. There was a change made to allow builds to complete when using fingerprints to track items associated with the build. Okay, that's good. And then in Jenkins to 292 we see that there was an update of stapler from version one but 263 to this other number. There were changes related to pipeline builds and removing bundled plugins and build progress status animation. These are the kinds of things that are commonly expressed in these changelogs and what these changelogs actually go ahead. Yes, I was just, I'm, I'm able to understand what you're saying yes. Okay, and, and this changelog that we're seeing a prototype of it is actually generated for us automatically from the content of the poll requests in GitHub. So this is an example of a poll request that was submitted to a previous Jenkins weekly release. And here is the proposed changelog entry that the tools automatically extract for us. So we get the benefit that other people do much of the writing for the changelog and certainly they provide the content that then the tools extract for us and tell and give us a prototype that we can use to to define the final changelog. So we, I will run some will run some tools, having run those tools will then edit the resulting text file will then generate the Jenkins that I oh site ourselves and look at it, see if it looks correct, check that it's well behaved. And, and then if it does will submit a poll request for the changelog. I understood so these details will be extracted from the PRs that have been merged in past, right. Correct, yes, exactly. Okay, okay. And what about this community reported issues, like, if you can see 2.293 in that it says one times of Jenkins 65665 one times of this this is also automatically generated right. That's, that's a very good question and so, so what you're asking is that what about this and these three icons, and this community report issues and these three icons are actually part of what's called the rating system. We have a facility that allows Jenkins users who are running a particular release to give feedback to us without the overhead of a bug report without all the work of other things to say, for instance, if they click this image of the sunshine, you'll see the hover text tells us no major issue with this issues with this release so when I click that it pops up a dialogue that says thanks, and it incremented by one. Now if I click this one, it will say, Oh, you had it and let's first cancel, if I hover over it. I, the text is I experienced notable issues. So if I click this it asks, please provide the issue number for of that's causing the problem. And so, in this case, if I would if you could see here that there were 13 users on 2.292 that that entered Jenkins dash 65611. This thing as a bug report. And that that set of this problem actually is what caused us to do 2.293. So, so this rating system helps us to know what are the hot problems for users which things are getting in their way now. We get junk in here sometimes like for instance this Jenkins dash 69. If I open that you're going to see it has nothing to do with anything on this this is a bug that was fixed 15 years ago. People can and do spam us and we have intentionally chosen just to ignore spam in the rating system. It's just not been a big enough problem for us to do anything other than just ignore it. Any questions so far. This definitely looks very interesting so users go to the website and in this particular page and click on the icons and report what they were facing in the current version of Jenkins right. Correct. Yes, that makes sense. And this this storm cloud here. If we hover over it it that's the worst of all things that says there was a problem that was severe enough. I had to revert to a previous version. And this rating system that we see is available not just for weekly releases, but is also available for the stable long term support releases. So when I look at the long term support release changelog. Here we see, oh, with 2.277.4. There were 3838 reports of a rollback required. And 28 that encountered what they rate sign notable issues, and you can see the list of issues here. So the, the rating system is quite helpful for us to understand without the overhead of making someone submit a fully detailed bug report. Understood. That makes sense to me. So, so that we've we've seen the rating system. Now what I think we ought to do is let's, let's look at generating the how the how this thing is generated so it is generated from. It's generated from the contents of the Jenkins data ops Jenkins helps if my hyperlinks are working doesn't sorry just a minute. So we need the Jenkins repository. That's the Jenkins core. We need the the that's the core repo. We need the oops. Jenkins dash infra. Oh, no, this is wrong. It's Jenkins CI. Let's check these instructions before I type them wouldn't it. Okay, the Jenkins infra slash Jenkins dot IO. Docs repository. And we need the tool that reads from the Jenkins slash Jenkins repository and from GitHub, and can write a prototype changelog that will use for Jenkins dot IO. So those three repositories so core repo. Docs repo. And this is a basically a tools repo tool repo. So I'm going to go ahead and do that. Let's just copy this one. And all right so start with my director is empty so if I do I get clone of this, and there are ways to make this clone faster etc I didn't bother with any of those if someone wants to know about reference repositories and how to make things go much faster we can certainly talk about that. Okay, then I need to clone the Jenkins dot IO repository. And this one, I absolutely am going to use my tricks to make it clone faster, because I don't want us to wait the time gets in for Jenkins dot IO. Okay, there we go. Okay, so what that just did is I just cloned a 500 megabyte repository in a few seconds because I use this minus minus reference thing. Okay, so now I've got the core repository, the docs repository and now I need the tools repository which was this one. So get clone. Okay, so the, the crucial instructions are actually in the changelog generators read me file. It's easier if we, if we look at this from a web browser. So let's look at it there. So here's the read me. And what it tells us is this tool creates core changelog graphs, and we're going to focus on weekly. So the crucial script is generate Jenkins changelog. And I prefer it in Docker so we're going to focus on using it in Docker. The reason I prefer it in Docker is because then I don't have to worry about installing specific tool versions like which version of Ruby is required or which version of some other generator. All I have to do is I export my GitHub off which I've already done and I'm not going to show you because it's secret. And then I run this command. What's happening here is it's saying okay Docker run set an environment variable GitHub off with the value of the GitHub off variable I exported mount a volume for my current working directory as slash GitHub slash workspace. Remove things when I'm done this minus RM and run the program the Docker image Jenkins slash core changelog generator. So let's try that. Now this is assuming that the release has not already happened, which it has not in this case. So let's go ahead and do that. And the same exact text is available here I could have copied it just as easily from this location. Okay, so Docker run GitHub off minus the current working directory which is OPS. And now I've already made a mistake here and I'm going to show you my mistake and what happens when I enter on this mistake. It says, Oh, oops, you didn't pass a version number. This isn't a git repository. And therefore something's wrong. Well, I'm in the wrong place. Instead of being in core changelog generator, or in in this parent directory I need to CD into the Jenkins directory, because it's going to use the contents of the contents here to help it understand what should be in the changelog. So now let's try that same command again. Docker run minus see GitHub off equals map the current directory which is the Jenkins repository to slash GitHub slash workspace and run the core changelog generator. What I'm doing now is it says, Oh, you didn't tell me a version number so I'm going to use the last commit. That means it's going from Jenkins 2.293 to this current commit. And it's telling us what it's doing so it's found some things it found something from Angelique, and now it wrote a draft YAML file of the changelog. And if we edit that file will see it. So here's the draft changelog. And this thing has is a YAML file with data so the date this would be the date of the release and only be set to tomorrow because that's when we'll release it. And then one entry per pull request. And it does some sorting for us so it puts major bugs first. And then after major bugs it will put major RFEs and request for enhancement and then bugs I believe then RFE. It does some really nice work here and then it also places comments for things that have been intentionally listed as not needing to be in the changelog. And so far. You said tomorrow's date but you actually have what's yesterday's date in half the world. Right, so I have to update this when I put the final thing. Absolutely. All it can do is put today's date in. I then have to and when I, when I do this same exercise for something like Jenkins LTS, I will put the destination the expected release date of the LTS release. Okay, but you don't put that in the YAML file you put that in. Well, I will put that in the YAML file, but this is just the prototype. Okay. Other questions. Yes. So these are the bugs that have been reported and with the help of the tool, we have created a draft automatically. So how is this going to help us in making that page which you showed me earlier, having built icons and those. Yes. Good question. So this, this change log dot YAML is this prototype source that we will use to add content to a data file in the Jenkins dot IO repository called weekly dot YAML. And the weekly dot YAML is is the data file that's used to generate this HTML page. Yes, understood. So, so the, the, for me, the elegance here is, ah, I'm not actually writing an HTML page when I write the change log, I'm just making data entries. And this data then gets turned into a workable and usable HTML page. Right. Yes. So, so what we've done up to this point is we've cloned the three repositories. We've run the generator to create the prototype. Now what we need to do is we need to convert that prototype into weekly dot YAML. Okay, so that step is something like this. I think that I'm in the Jenkins directory for now so I'm in the Jenkins core. I need to change to the documentation directory because I'm going to create the change log in the docs directory. Now, and in this case, let's see, get remote add. Let's see what shall we call it get remote rename origin upstream. So I'm, I need to, I need to use, I need to have my use my own repository for this so I'm going to switch. So get remote add origin. Get at github.com Jenkins.io.get. And now if we say, if I pull everything. Okay. And I have to do one more little bit of tweaking, because I like things a certain way. What I'm doing is declaring that I want my branch name master to actually represent origin. Here we have it. The last change was this GSOC 2020-20105 updates. I'm going to create a branch change log dash 2.294. And now I'm ready to do my edits. So I'm going to bring up my editor. And we're going to edit content underscore data change logs. Notice that it's, this is data and not pages. And then we're going to bring up weekly, and I'm going to bring in at the same time Jenkins slash Jenkins or slash change log dot yaml. So what I'll have in the top half of my screen is the prototype. And in the bottom half of my screen is the current weekly. And the most recent release there was 2.293. So I'm going to put in some extra space and have a working area where I can do 2.294 questions so far. Okay, then let's go ahead. Okay, so release is 2.294. So the date will be tomorrow, the 20 or your date today already dirage, right? You're already the 25th. Yes. And then I'm going to just take one change. Let's see, let's take one change at a time into my text editor and you can use any text editor you want visual studio vs visual studio code whatever I happen to be most familiar with this particular editor. All right, so this is the proposed text. Now my job is to make the proposed text conform to the style guide. And the style guide is in this document in this file right here in style guide, and it will tell us this gives us good guidance on how we do it so use the present tense. And then use specific prefixes for specific types of things when up when describing an upgrade always include both the previous and the current version number of the upgrade and use complete sentences and end them with a period. So those kinds of styles are here. And, and then how what should the ordering be. It's, it's included in the style guide. I'm going to take this one and it says, okay, this one says fix an SSH CLI authentication. Okay, so I have to put it like this. And my general technique is go find something else that already said that kind of thing. And copy it. And now we have to I have to do some research to decode where when was that regression so regression and to do the data here tells me which poll request it was, and which issue it's fixing. So let's go look at that, that issue, Jenkins CLI unable to read SSH. Ah, and here's what we've got it so it says the user says they upgraded from 2.2 80 to 2.285. And now we should be able to see. Downgraded to 283 so the problem is likely in 2.284 and as we read further in this we would to see the description. Oh yes, it is something happened in 2.284. And here is the problem. So the regression was introduced in 2.284. Okay. So, and now I have to worry that CLI. Oh, it's actually pretty common. Okay, let's see. Command line, because make has taught me that I should avoid three letter acronyms when I can. Okay, so there is the first item inserted into the changelog. Any questions so far. Can you confirm by regression we mean that this current issue was introduced in which version of Jenkins. Correct. The regression in these cases a way of saying worked correctly prior to that version broke in a version, and this is now restoring the correct behavior again. Yes, okay, thank you. Yeah, very good question. So let's do the same thing again this time with the next one on the list. And it says, okay so it says another major bug bridge methods are no longer present. And so what the proposed changelog says, restore bridge methods used to retain backwards compatibility. And now I don't know if this one should be flagged as a developer issue or not because it's, I'm not sure how users will see this we like the changelog to be expressed in terms, the user will understand. I'm not sure that a fixed SSH command line interface authentication, I think a user will understand that. I'm not sure that a user will understand restore bridge methods used to retain backwards compatibility. So let's take a look at it and let's see if we can find better words that we might use to describe it as an example that might work for a user. So, so James describes it. Oh, yes. Okay, here we go. I think. The challenge is I'm not quite sure how to describe it because what happens is attempts to compile the promoted builds plugin fail. And that probably means that the plugin will also fail at runtime. So, so it's now, but but it's not just promoted builds promoted. Yeah, it's not just one plugin, it's that any plugin and that's why he described it as bridge methods right so so what we've got is something that fits for developers but I think maybe what we should just do is describe it as fix. No such method error when loading certain when using certain plugins with that, that be a better description. It's not just to leave the bridge thing but just have like a quick parent that'll go the bridge methods that are used to ensure that such and such, or that backward compared it used to retain backwards compatibility. So something like this, rather than reporting. Not that. It's not just reporting it's actually going to fail right it's, it's going to work that would be a plugin that's not brought up to date. What backwards compatibility is affected here I don't know that well in this case it's that a current release of the promoter builds plugin will not run correctly in this environment with with until this is fixed. Right. The bridge methods used to retain backwards compatibility rather than reporting no such method error at runtime for a plugin. Yes. Well, yeah, so the no, no such method error I suspect is is going to just be generally displayed. We don't necessarily know that it's for a specific plugin. So another alternative might be a fix. No such method errors when using plugins that rely on bridge methods. What do you think of that. I mean it's so bridge. So the, the ideal solution, I mean in the, you know, ideal world, the plugin would have been modified to not use that method. No, no, actually I think it's intentional that that that method is allowed. Okay. So just trying to trying to find good phrasing. Oops, now we don't need to two hard stops. So that phrasing Meg. I'm still understanding then why this is backwards compatibility. If it's, if you're saying it's not, it's sound at me that backwards compatibility sounds to me like, ideally, the plugin should have been written differently. I see what you're saying. Okay. But so what if we take the way I'm talking about. Yeah. Fix no such as method method error when using plugins that rely on bridge methods for compatibility regression to that 278. That's probably good enough. I mean it's, you know, your average user it's not going to make, but if they've seen that error, they'll recognize it. Okay, doesn't matter right. Let's let's hope for that then so we've converted one dirage. What do you think does that work for you. Yes, totally. Let's take the next one then. All right, so this is an enhancement. And the proposed text is remove the requirement for locking the queue when adding a new note. That's pretty good to me. Now users. I think we can safely assume that they'll know understand the meaning of the word node in this context, and what a queue is, etc. So, in that case, I'm, I'm not attempting to explain those concepts just bringing it in. Right if they don't know that much they can trouble in the change log anyhow probably. Right. Okay, now. So this is an enhancement. This one is to lessen the severity when of the message that's displayed when an update is not available. Fair enough now Meg is IE the correct thing here is at EG. No it asked. Or no well do they mean do you mean for example or do you mean a given release line. Yes. So in this case. Latest version of a given release line there are two release lines weekly and stable the stable is also called LTS. So, I assume that's correct usage then I get or I mean is is what he means to say is LTS. Even on the latest version of an LTS release line is that what he's really saying. Correct. Right so why don't we change given to LTS and lose the well because it could be it could also be weekly right. Oh, okay. Okay so I'm going to go ahead and assume that's okay let's take on the next one. All right next one this one has some interesting noise in it that we're going to have to fix out. And I'm never quite sure why sometimes they get noisy like this. But it's easy to fix it's just YAML. Was it supposed to be a bullet list is that what it is or I don't know why the tool generated it that way but it did. And it's easy to fix so the new line here each one of those is in fact a line break. So if I want to make it first look like what they intended. I just do it like this. I'm sorry that you're having to watch me do these edits but they help me help me see things better before before I actually propose what I think this thing should be. Right now it's useful to see how you actually do it. Okay so this one has the nicely that it can also illustrate the concept of references and how to refer to an upgrade. And it says bump promoting from 4.7 to 4.8. So that's what the change log entry should be is it should be upgrading from, and we could even see if we've had one of these before. There it is. This is how it was described previously upgrade from and so I just go back in time. And then we grab one of those and say upgrade from promoting 4.7 to promoting 4.8. And then there was this little thing here, the references. This allows us to embed additional references into the end of the line. The output so if we look back here at the change log. You'll see here for example, on this update stapler, there's one hyperlink for the pull request, one for the stapler change log, some version and another for a different one. So I need to add multiple, multiple links to the end I use this references references data type, and I like to put the issue number. Okay, and then this has in it, the link to the change log for 4.8 so I put that here as that, and the 4.8 change log. Okay, now, I don't know. Now I have to think about this because in the past we haven't bothered to enumerate each of the bugs in in the in the change log. I thought there was the other remoting the one you copied I thought it had a bullet list after it. So here it says upgrade from remoting for six to remoting for seven maybe there's another one I was hallucinating. This one talks about. Well and see these previously used internal, which probably should be used here as well, because this really isn't visible to users. Right. I mean if this it is an important update but it is internal. Right. And then the question is do all the do these things matter to users. And when I look at them, I don't think so I think we should just call it. Yeah, I'm going to just go ahead and take that out for now. Any objections. Now it's entirely possible that that's a mistake so next one though let's do it so this one is RFE to improve localization and Angelique is the author. And she's updated terminology for French for the word controller. Now RFEs would go above internal. According to the style guide so I need to put this above this RFE internal. Okay, and then bump bridge method annotation. This one. I think should just be suppressed because I don't think that users care about an internal upgrade of a component. So I'm going to take that one and turn it into a comment like these other comments. Oops. So if we look at these comments, you'll see many that are like that where they say bump this or remove this usage of something that's not visible to a user or fix something in a test. And I'm going to make a same comment here that says PR 5501. And it is bump bridge method annotation. So the reason I put it here is a comment it won't show to the user but I put it as a comment to be sure that if others ask a why did you do that. They had they can see that I at least thought about it. Likewise, I need to do the same thing for this front end maven plugin that was done as part of 5490. So I copy that line color 5490. So dirage, are you seeing what I'm doing. And any questions so far. No, it is making sense to me. Okay. So here we've got 5490 and 5501. Both included now we've got one more. And this one is update extreme from one dot four dot 16 to okay and this one. And this one is me knowing some things that others may not know extreme is a particularly important library. So usually when we update it, we acknowledge that update in the changelog. And sorry, I don't know how to highlight it other than by saying, yes, it's, it's important enough that when we update it we, we note that so here is the example that I used before. Yes. Alright, so we did it as an RFP. We're just going to steal that same text. And instead, it will be from one dot four dot 16 to one dot four dot 17 and the author is on the on the poll request is 5498. And the issue. No issue was. Oh no, the issue is there. There it is. Okay. Okay, so we've captured RFE RFE 5498 6. Okay, now we've got to do the changelog and it's probably 17 instead of 16. And let's double check that that actually resolves to the changelog. There it is good release May 13. Okay. Right. So I think that's correct. Oh, now let's see how did. Yeah, that's how it was done before no long list of anything just updating it. Okay, questions so far. So, as you said, the extreme library is very important and we should not put it among the comments. So, how do I know if I'm working on it when I said that this is the one that is important. The easiest way is if a library is being updated, you can search backward through the changelog and see if it was mentioned previously so for instance, if I look backwards for spotless. I should see all I see it in his comments. If I look backwards for structs. All I see it in is comments. The first indication for me is look at other libraries and see if other copies of the library in the weekly changelog see if they were described as a separate item or as a comment. Good question. Very good. Also, while we're on it, I just also want to know if there's any way I can do this searching in VS code as well. Yes, yes, absolutely. So you can search backwards. Just, this is just a YAML file so you bring it up in VS code and use whatever your preferred searching techniques are in VS code. Absolutely. Okay. Yeah, you'll find I suspect you'll find the VS code YAML editor quite comfortable. And yes, it will behave the way you expect so that that makes it really great. In my case, I haven't made the switch to VS code because of some tools in this particular editor that make my life much easier. But but VS code is great for to editing YAML files use it by all means. Okay, so I think I think we've completed it. I need to look at the discs just to be sure. So there it is 2.294 and added all the content. Okay. So now, oops. I'm now going to run the make. And this relies on me having been able to build the doc the Jenkins that I oh site already. I assume that you've been able to do that dear. Oh, yes. Okay, good. So I'm going to make run. And what this will do is it will generate the site. It will generate a subset of the site based on what it sees. And then when I click load on the page, it will generate those pages as necessary. So right now what we're seeing is the site builder constructing itself on this on this machine. And it'll be a minute or two here while it's working through that. And this scripts bundle exec. What this does is asks for what is the current version of Jenkins it's being delivered. It asks a question to the, the Jenkins update center, extracts the current version then it will use that later. So now it is pulling in the npm Docker image. Now it's running awestruck. This thing right here which is the site generator, and now it's generating the site. And now if I open my web browser, we should be able to go to that computer port 4242 and here it is. So here is the site. And now if I click download. This one is showing me 2.293 and I would like to see 2.294. So I need to make a change here. That's a good thing to have remembered. Okay. Force. So I have a, I have a script that I use called force latest core that lets me tell the generator to write a very specific file into this location. So, I'm going to run that thing now 2.294. And then I'm just going to rebuild the site. So this is going to generate. Instead of with the most recent Jenkins release, it's going to generate, assuming the most recent release is this number that I told that it is. So, back to this site, the current actual release is 2.293 2.294 does not exist yet. In order for me to see something that does not exist yet, I had to update this, this file. So now let's go, the, the files that are mentioned in that script. So now let's reload this page. And there's 2.294. So fix SSH command line interface authentication. And notice the bold read the larger red dot that means it's major. The smaller other color dot here is not major and then, oops, I have a mistake internal should always be below. And so I need to go fix my mistake. So my mistake is in this file. And the mistake was that internal is the lowest priority. So this thing should be moved below X string. Now, when I did that, if I refresh this page, it should show it correctly now extreme update is first. Internal is last question so far. Yes, so just to check if I got this out or not. So the pull request that we have all the issues are everything that we have mentioned here. Those are the reasons why we introduced 2.294. And on the icons that we see the three icons, those are just a way for the users to, you know, pitch in their views on how this new version 2.294 is working out for the right. Correct. Yes. Okay, got it. Yes, and I think if I click these, they may even increment, but it's unhealthy for me to click them because I'm not actually running 2.294. But yes, yeah, I think you've said it exactly. Those icons are there because they'll be there on the final page. And this is the data that I had entered. Now, when I submit the pull request for this. It's asked that, hey, please submit the pull request. Oops, I need the size or command just a minute. I'm missing a very helpful program that lets me set window sizes. So Sizer will let me set this thing to that width. Okay, now I need to capture a copy of this because readers who are looking at this pull request won't find it easy to read the YAML file. It's much easier for them if I give them a picture of how it will look. So here I've copied that into this image. And now when I submit the pull request, I'll paste this image in so that they can see how it looks when it's rendered. Okay, so I'm going to commit the change. So change log 2.294. And now I'm ready to push. And for me, it's easier. If I do this now with GitHub with the GHPR command, because it does an awful lot of things for me so GH is the command line get interface and I'm going to do GHPR create. And it's going to ask me some questions. So which should be the base repository, the base repository the one that is the, the ultimate destination for everything, the base should be Jenkins-info slash Jenkins.io. Now which where should we push the change log branch, we should push it to my fork. And now here's the it's asking for the title, and we're going to say yes we'll take the title as is. And I could either press E to launch an editor or enter to skip and I'm going to hit enter. It's now ready to submit my pull request. So now it's submitted this pull request and if we go here, we will find that pull request. So here's the pull request for the change log and what I'll do is edit this and back to my copy thing here. Copy this and paste it there. So there it is. So this is the proposed change log for 2.294. So it looks like this and the changed files look like this as the YAML file with all those comments. Now, reviewers, it's, it's not, it is quite common for reviewers to detect a mistake I made and say hey could you fix this, could you fix this don't be, don't be intimidated by having mistakes detected in what you're creating that's what happens. Dear Raj, I wonder if maybe what you and I should plan is that we'll do this next week but have you drive it and me watch. Would that be okay with you. What do I need to do. I was going to have you do the same steps I did next week for the week weekly release, but I'll watch over your shoulder and talk through it and we'll do it together but this time with you typing instead of me. That would be really helpful for me as well. I just think that way I'm still available next week, you and I can go through it. And even if we fail terribly, we've learned something in the process. Of course, yes. All right. Sorry, I took the entire hour for this topic. My apologies. Other other topics that we need that are hot for us. Dear Raj, this change log generation for me is a crucial thing that needs help on this ideas of things where people can help. There were some other suggestions. Let's see in, for instance, so generate weekly change log was the one reviewing documentation pull requests is certainly another place where you could be helpful if you've got time and capacity. And this one is preparing doc for the document for the contributor summit. And this one, I think Xenob Abu Bakar is wanting to take it on if she can. So if you don't mind not being the leading the documentation track but just being a participant. I think she's interested in leading it. Sure, that works for me. Great. All right, Meg anything else we need to discuss. I'm going to go ahead and call this a session dirage will plan on doing next week will do that you and I will do the change log together for 2.295. Awesome. All right, I want to congratulate you for completing four years at cloud bees and if I'm not wrong, right. I'm sorry what was that. So, I wanted to congratulate you for completing four years at cloud bees. Thank you. That's very kind of you yes it's, I've hit my fourth year anniversary. I'm also yesterday was my 60th birthday so yes it's been a momentous time. Thank you very very much thank you thank you. All right, we will talk to everyone next week we've also got office hours Thursday where we'll talk with Xenob dirage no reason for that you have to be there Thursday you're certainly welcome to attend again if you wish to. Sure. Thank you. All right, thanks everybody. Thank you. Bye bye. Bye bye.