 Welcome to Docs Office Hours. It's the 2nd of December, 2021. And delighted to talk to documentation. Remember, we abide by the Jenkins Code of Conduct. So today's agenda, modernizing a plug-in blog post. Yiraj and I are working together on it. And if time allows, and if it's not too much, we may review Gavin Mogan's election results blog post. It needs to, it's scheduled to post tomorrow. So we've got time to do the review. And if I need to review it myself, solo, I can. I think this modernizing a plug-in blog post is the big topic. Definitely. And from my side as well, can you also talk about the copyright editing topic? I wanted to know. Oh yes, triage to you. Yes. Yes, yes. Well, in fact, let's put that one first, Yiraj, because that one, I think we owe that one first. And good, very good. Okay, any other topics that you'd like to be sure we include on the agenda? Nothing as of now, but maybe if time allows, we can talk about LTS guide as well. I had a few questions about that as well. Okay, let's put it back on it. Change log and upgrade guide. Yes, good. Okay, so let's do that. Okay. All right, so triage team and copy editor process. So let's look first to see what the context is here. So github.com slash Jenkins dash infra. Too many characters in the URL. So if we go here, across the top is teams. And now if we search for triage, here's the Jenkins.io triage team. And so what we see is we see five members, me, Oleg, Meg, Kristen and Dhiraj. And then how many repositories? It controls one repository and it allows triage permission. So you can read, clone and manage issues and pull requests. So now I wonder if that means that you can merge them. We may want to test that. So I didn't think it gave you merge permission, but yeah, okay, I think it does not. In this case, when they say manage pull requests, I think it means that you may be allowed to do things like close them, but you can't merge them because I think that requires right. So could you, okay, you say you can close them and edit them? Or was that a question? That was a question, yes. Okay, so well, so let's go do an exploration to check that. Could you bring up your web browser? And I'm gonna bring up, I've got mine up and let's look at some pull requests and we're going to see what actions are available to you. Okay. So for instance, take the very first one, 2021 election results and it's marked as a draft and I assume that you cannot mark it as not a draft. Does your screen have the ready for review button on it? Sure, can you share the link with me please? Oh, I sure can, yes, you bet, absolutely. Yeah, sorry, of course. Let's try this. So chat window is the PR. Okay, so in the Zoom chat, you'll find the pull request. Yes. So you're suggesting me to do? So open that pull request. You should see a, you may see a request for review across the top. I'm not sure if triage team members are automatically flagged as reviewers or not. Okay, but you do see the draft identifier, right? Yes, yes. And then if you scroll down to the bottom, do you have the option with this ready for review button to say I'm going to pull it out of draft? I assume you do not. Yes, I do not have it. Okay, all right. Now, if we do, let's do something different. I think if you, if we have you open the issues page and I'll paste this link as well, let's have you go there and see if you have the button to close this issue because I think you do have that option. Yes, close issue button right next to comment. Okay, so, and that was, I suspected the capability you didn't have before. So you have, you've always had the ability to comment but now you can also close an issue. This is not one we should close but just knowing that you've got it, that's a permission that I believe you're granted by being part of the triage team. Right, okay. That's great. Now, back to the election results. I assume that you don't have anything. Oh, no, let's find one that's been approved. Here's an approved poll request. Ah, here's a good one. Okay, so could you open this one? I'm going to post the link to this one. I want to see if you have permission to merge a poll request once it's been approved. Okay, so this is open and if I scroll down, I see that there's an option for close poll request. But you don't have the green button that is merge poll request. Oh, I do not have that. Okay, right, so, and that's consistent. You get that when you become a copy editor. So we'll have you remain as a triage team member for two or four weeks at least. Then after a period of this, like this mentoring, then we'll submit the request to the Jenkins developer list asking that you be granted permission to be a copy editor. And considering how few copy editors there are, we really need you. Awesome, that sounds great. Okay. Yes, so this triage time is where I'll be learning things and after I have learned the things, then I'll be getting the rights for copyright editing team, right? So for copy editor, yes, that's correct. Copy editor, okay, got it. So they have more privileges like they can merge poll requests as well. That's correct, yeah, that's exactly. So copy editors, copy editors. And if we look at that group, we'll see that there are only four of us. So it's like I can merge any PR that comes to Jenkins. When, well, you'll be able to merge, as a copy editor, you can merge any PR that is, I think as a copy editor, it will require that it has to have been approved, but you can do the approval if it's not your PR, you could do the approval and then you can merge it. Okay, that's good. I'm not, yeah, that's why we want some training time for you so that you don't, no, thankfully it's just git and therefore we can always revert your commit. It's very easy to revert a mistake. So we're not frightened of people's mistakes. Mistakes happen, we fix them. But I don't know that it will give you this permission. So let me show you this one where for instance, this is a draft item and I don't, I'm not sure if copy editor will let you uncheck the ready for review. So I'm not sure it will allow that. And even if it does allow that, I don't know that it would allow you the permission to do what this one will allow me. Oh, no, this is still another one in draft. Let's pick one that's not draft like this one. Okay, here I could preemptively check this checkbox, use your administrator privileges to merge it without satisfying requirements. And then I could just do the merge, but I don't think that will be yours because I don't think you're an administrator when you're a copy editor. Right, okay. So you can do plenty of damage, but not catastrophic kinds of damage whereas an administrator can do terrible catastrophic damage. Yes, that's true, got it. Any other questions on triage team? No, nothing as of now. Okay, all right. Well, thank you and welcome to the team. Thanks for accepting the invitation. Thanks a lot. Okay, so reviewed the process and the permissions. All right, LTS changelog, what questions does you have there? The questions were like, so if I had to do a contribute to this, what should I be doing? And what did you do this time? So just I want to understand the contributing part of this that I can contribute better. Great, okay. That you explained to me previously as well on IRC, but there were so many numbers and that confused me. Well, and I think it's good for us to record this. So this is a perfect excuse for us to do a recording like this and say here are the steps that are commonly taken. So how is the changelog assembled? How is content chosen? How is the upgrade guide? How are the upgrade topics, upgrade that guide topics selected, right? So, and I think those are all very good things. So let's start with each of those and go through sort of a tour of them. So the changelog is two parts and there's the back ports part, which is changes since the base, the weekly baseline. For example, that means we released 2.319 weekly had some bugs. We didn't want to ship those bugs, bugs in 2.319.1. A back port was proposed and accepted and merged. The changelog documents those back ports in the changes since 2.319 section. So now let's look at that to be sure that it's clear. So, okay, so let's go here to the download page and if we look at this one, changes since 2.319. So this is the first section and these are all the back ports and almost always every back port is included in this list because it's quite rare that we would include a back port that is not worth mentioning to a user. If it's not worth mentioning to a user, it's usually not worth back port it. Okay. So this, go ahead. Yes, so if I may, can you ask tell me about the download back port again and the baseline for these terms? Yes, yes, absolutely very good. So the baseline, the baseline of 2.319.1 is the weekly release on which it was based. So it's 2.319, that's what I mean when I say baseline. So that is the same weekly change that we do each Tuesday, right? Exactly the same, yes, that's correct. So the 2.319 baseline has just changes between 2.318 and 2.319, but that release happens to also include everything up to that point. So changes in 304, 305, 306 are all in that weekly release cumulatively. Okay, that makes sense. So we start with a weekly, 2.319 that weekly has some problems. We found those problems over the course of testing the weekly and these back ports are proposed copies of the cherry picks actually of the fixes for those issues we found brought back from later weekly versions. For example, this one was fixed in 2.322 and the fix was brought backwards to the 2.319 base so that it could be included in 2.319.1. Okay, so we brought back something from the future weekly change lock to this LTS guide. Exactly right, yes, that's right. We cherry picked something backwards, yes. Okay, to include it in this one. Okay, so how far can you go in future to pick something and bring it to this one? We could go all the way to any weekly release that had happened after 2.319 before the release of this LTS. Oh, the release of this LTS, okay. Okay. Here, let's walk through a scenario because it's a good one to walk through it. So 2.319 has a bug. The bug is it's missing a hyperlink. The build history used to have a hyperlink in the list, the hyperlink is not there anymore. It was that bug was introduced at some earlier version wherever it was, but it's missing in that release. We don't wanna ship that to a user. 2.322 fixes that bug. The hyperlink is now in the build history page. Okay. However, if we don't do something, 2.319.1 will include this bug because 2.319.1 is just 2.319. Right, yes, yes. So if we don't cherry pick the fix back to stable dash 2.319, the bug will be in 2.319.1. Yes, so I was wondering why are we picking something from future weekly releases? Now I know because the current 3.2.319.1 is not something like that we want to show to use because it is just a statement saying that we have this bug and we actually want to show them a fix of that bug and which is in the future one, right? That's right. Yeah, exactly. That's great. Yeah, so we made a mistake in 2.319 the weekly. We fixed it later and it is an important enough fix that we want to make sure that the LTS based on that does not have that bug. So we backboard it. Right. So the LTS, the main LTA, 2.319.1 that we are building out of this weekly 2.319, it will have all the entries of, all the valid entries of 2.319 and some fixes of those from the future weekly releases. Or is it what it's going to have? Yes, you said it exactly. That was precisely correct. What you described is exactly what happens and the process of choosing those things, which things are so serious, we need to backboard them. There's a process that we follow to make that choice. Okay, and before that, so if we are basing all the entries of 2.319.1 on this one weekly change log, I see in the output of this monthly LTS change log that there are lots of entries. So I'm wondering how all these entries are getting generated out of just one weekly change log and few of its future fixes entries. Okay, so does that make sense? I'm not sure I'm understanding the question. So let's go look at this together. So I think you were asking, how does this list get assembled? Is that what you're asking? Are the notable changes since the previous LTS or did I misunderstand your question? Yeah, my question was just exactly this. Like we are just basing our, can you scroll up a little bit? Yes. Yes, so what is that you call this 2.319.1? What do you call this 2.319.1? So it's an LTS release. Is that what you're asking? Yes, yes, sorry, I forgot the question was, sorry. So the question was, how is this file so big, the LTS release file, because we are basing it only on a weekly change log file, which is comparatively small, right? Well, good. So you asked exactly the right question. So the earlier discussion talked about how we assembled this piece. These are back points. Now you've immediately taken us to the next question is, how do we assemble this piece? And what is it that chooses things to go there? Because notice the word here is notable. So this is telling me a human being reviewed all the changes and decided which ones were important enough to be notable. And so this though is since 2.303.3, so 2.303.3 does not have any changes from 2.304, 2.305, 2.306, 307, all the way up to 318 and beyond. So this section is saying a human being thought about all the changes and decided which ones to show you as having changed since 2.303.3. Oh, okay, so we have collected, first of all, we reviewed all the weekly change logs right from 2.303 till 2.318. And after reading all of them, we have decided like which one would we want to pick from them and present it in 2.319.1, right? Correct, that's exactly right. You said it just perfectly. And the reason we are showing them because all the weekly change logs from 2.303 till 2.318 were not shown in the previous LTS release. Yes, exactly. The what's new in 2.303.3 doesn't know anything about what's in 304, 305, 306. All it knows about is what was actually applied to 303.3. And so this does not include, excuse me, all of the new things added in 304, 305, 306, et cetera. So it has to be mentioned here if it's notable. It's mentioned in notable changes. But there are some things might be missing from 2.303 till 2.318 because some of them might be a fix for 2.303 if I'm not wrong. The previous weekly change log on which the previous release was based at. What is that? Did I confuse you? Could be, well, so the changes will be changes made in 2.304 and later on weekly. Those are the candidates for possible inclusion in this list. And then we review the candidates and decide which ones should actually be included, not just our candidates. Right. So some of the, among all the select, while you're doing the selection, some of the entry would be those which were part of the back ports for the previous month, I guess release, right? Okay, say that again. So the back ports definitely are included, but the back ports would not naturally be visible here because they are back ports of something released after 2.319. And this is only 2.303 up until 2.319. Right. Yeah, that makes sense. Got it. I was confused previously. Yeah, so I wonder maybe it would, yeah, I may want to consider diagramming because what this really reminds me is that we've got, yeah, let's see if I've got, hang on, we've got to try this. I, remote is much more difficult than being with you and me sitting around a whiteboard together. If I took this and said, okay, here we've got 2.303.3, oops, three. And here we've got 2.304 as the first and then a number of dots, 2.305, okay? And then all the way down to 2.319. And so the thing that goes into, we then branch and create a branch here called 2.3, it's called stable dash 2.319 and from it, we'll release 2.319.1. And what that includes is these changes plus, let's see, plus what, 3.9? Weekly is there. Oh, oh, right. And then this was what I was trying to illustrate. Then 2.320, 2.321. 2.321. And here we've got some sort of a dashed line that brings some things back. Go ahead, sorry, Dheeraj. So these might be the backpots that you were talking about. Yes, exactly. You understood it. Sorry, my diagramming is very poor, but yes. And so this black line is represented by the, the change log description of the things in the black line is described, oops, is described seriously, here in notable changes since 2.303.3. And it's described there because those are the changes that happened on this line of development on the right-hand side. Okay. Okay. Can you also do the same diagram for the previous one? Like a little bit. Sure. Yeah. So for this, you mean for this section? No, for the, can you go back to the diagram? Okay. Yeah. For 2.303.3. Ah, yes. So where did it get its changes from? Yes. Good, very good. So then I can see a pattern between two months. Right, right. Very good. Okay. So 2.303 received its changes from, from actually let's look because this will give us a hint. Security fixes were necessary there, agent, and this fix, and that fix was first implemented in Jenkins 2.313. So, right, exactly. So back to our diagram. Here there was a version 2.313. We're going to put one right in here. 2.313. And one of the changes, just one, but one of the changes from that was back ported all the way to there. Right. And so it was a fix to an issue, right? It was. Yes. That issue first came on which weekly release? That issue first came in this case on a weekly release, probably 10 years ago. It's that old of a bug. Yes. This particular bug is that old that it happened. And if we were to read the description here, we would see, yes, this bug appears to be a very, very old bug. It's somewhat unique in how old that bug is. Okay. Okay, so, and, but back to our diagram, this thing, one change here, and then if we do 2.322, there may have been two changes that were merged from there back. And those then appear in that backports section because they happened after the weekly baseline. Right. Sorry, this kind of conversation at 11.30 at night must be almost impossible. I'm sorry to do this to you. Is this helping you? Is it, are you, are you envisioning it? Definitely, I am loving it because without this, I would, that would be more difficult, but this makes it easier for me. Great. Okay. Thanks for that. And you use this term weekly baseline. So it is, it is a weekly release that we decided, okay. So this is the weekly release on which we'll be basing our LTS release, right? Yes. In this case it is 2.319. Got it. Okay. Yes, that is correct. Okay. So this 2.319 and we are backporting some changes from the, on 2.320 and onwards weekly releases. Some of those fixes, the changes, which are entries, which are mentioned in the weekly baseline. And and so that will be in the first section of our release. And on the second section, the notable changes, it will have all the cherry picked selected entries from the previous LTS release is weekly changelog till my current weekly changelog, right? Yes. That's exactly right. Yes. That makes sense. So just to say exactly what you just said because you said it beautifully. It was this, whoops, where is it? This, where? Yes, okay. So this section right here is the curated or human selected changes that we've decided to highlight since the prior LTS. And so just as you said, now you use the phrase cherry pick. I'm used to using that phrase only to refer to get commits. And this is done by a human being to rather than by using get cherry pick. But the same concept still applies. This is a human chosen set of, oh, here are the things that are valuable to users and we should mention. Great. That makes total sense to me now. Great, excellent. Good question. Any other questions on the selection process? Yes. So now that I know what the concept is and how do we decide things, not decide exactly. So I wanted to know how would you decide which notable changes would you pick from the previous weekly change logs? And the way I did it was systematically I bring in all the weekly change logs into a file that are relevant. So I bring in, I brought in 304, 305, 306, 317, 318, all of them, brought them into a file. And then I began deleting lines or deleting sections for the things that I thought, oh, that's not relevant to a user. That's not relevant to a user. So I created the subset by doing a copy everything in, delete things that I thought didn't matter. And then I did a grouping exercise to collect things that I thought were related to each other near each other. That's why you see modernize the Jenkins manage screen and the Jenkins build history and appearance of the feed bar and layout. If you look at their, right, exactly. And if you look at their pull request numbers, their numbers are quite different. 5507, 5664, 5692. So these were not immediately adjacent pull requests, but they were, I thought related to each other as a theme. Right, exactly. And you also marked their priority of the severity, some level, right? That is why the first one is, it's bullet is biggest. That's a little bit. Oh, good point. Yeah, so this one, this one was what's called a major request for enhancement, a major RFE. Yeah, exactly. Whereas this one is just an RFE. Yeah, good point. The larger bullet is because this is major and the others were not declared major. Right. So the change of style garland does it apply here as well? Like if you selected a developer one for some reason, would you still place it at the end? Yes, as you'll see here, this is a developer one. The Woodstock implementation, Woodstock's implementation was removed and it's not detected by users unless they have one of these critical plugins. This internal was put at the end because it offers something that users might want but it's entirely experimental. Right, that makes sense now. And one last question on this is why do we do this with general question and how does it help the users and what users are we talking about? Okay, so why do we do the subsetting? Is that your question? Why not just show them everything? No, why do we do monthly, why do we do LTS releases? Oh, oh, I see. Okay, so LTS releases are for users like me who aren't ready to accept the risks that come with a weekly release because weekly releases may surprise me with things that are broken. LTS releases have the benefit that they've had additional testing time and additional evaluation time before they're delivered. So as an example, 2.319 was selected as the baseline and went through about four weeks of evaluation of any bugs in it before it was actually delivered as 2.319.1, the LTS. So it had effectively four weeks of community validation of the weekly release before it was delivered as an LTS. Right, that makes sense. Because in weekly, as you said, it has more risk because they can be some things. But in LTS release, they are fixes to those issues in the form of back ports. Does that connect? It does, yes, that's correct. Okay, so that's why. So it's like a more secure option for users to switch to or upgrade their Jenkins, right? It is, it's called long-term support because it's intended to be more stable than the weekly release. And so the LTS, the long-term support release gets extra testing before we deliver it and then lasts longer as a stream of release. So we stay on the same baseline for three months. Hmm, exactly. And one last question again about that meme that Gavin shared. So there was a big jump from a very old LTS release to a new one. So how is that a problem for them? Ah, yes, yeah. So and that story is even a little more glaring because what happened was it was a jump from a long ago weekly release to a current LTS. So the user had chosen a particular Jenkins weekly 1.625 or something. And 1.625 was released six years ago. The Jenkins project does active development on the current release and fixes security bugs in the current release for weekly. It does not do anything on older versions. So that user was six years out of date for security fixes and all sorts and plugin updates, all sorts of things that that's a very long time ago. And so what's challenging now is that means the user really, if they want to be thorough, they need to read the upgrade guides since 1.625, which means if we look at this page, hey, I'm still scrolling, still scrolling, still scrolling. Okay, there is an LTS version in the changelog for them. But if we look back, let's go see where the last one, the most recent 600 series was and 609.1 2015, six years ago. If we go to the next one, it's still 2015. Again, still six years ago. Now maybe it's, oh, 625. Okay, there you go. It's December of six years ago. So I do have a question around this, but that is because I don't have much knowledge of Jenkins, but why do we need to read everything? Why can't he just directly upgrade it to the latest version and just open? And many people do exactly that. What I was trying to indicate was if you want to be very thorough in your upgrade, you need to know what changed between your starting point and today. And in order to know what changed between your starting point and today, you have to look at this pages and pages and pages of changes. And then you need to make a decision. Is that change relevant to me? No, you described exactly what most users do. Most users say, I don't care what the changes are. I'm going to try it. And if it works, I'm going to be happy. And if it doesn't work, I'm going to be sad. So you said you need to read through them in order to be thorough with the changes, right? Right. So that is just for the benefit of the user so that they know what all happened between this period. But if they just directly change it to the latest version, it won't, in the best case, break their system, right? We hope. We hope that it works just great. We really hope that. But considering the number of major changes made just in the last 12 months to Jenkins, I would expect all sorts of surprises on a six-year upgrade. So it's like a good practice, like to know the changes that happened, right? It is, yes. It's a very good practice to read what changed and think about them before you do the upgrade. As an example, this one, if you haven't thought about it, may surprise you significantly. Wow, you changed. The thing that used to be called master is now called built-in. How does that affect me? What does that damage? So if I would not have read that, I would be surprised with this term called controller, right? Exactly, right. The shock, oh dear, what do you mean? You changed this. Well, the reason we write an upgrade guide is so that people, and it changed like it, so people know we changed this. Mm-hmm. It makes 100% sense to me now. Great. Anything else on upgrade guide assembly? No, just when will we be having the next one? Three months from now, right? So the next LTS will be approximately four to five weeks from now. So we release a new LTS version every four weeks. Every three months, we release a new baseline. So the next LTS will be 2.319.2, then 2.319.3. And after those three months period, then we'll switch to a new baseline, 2.330 something probably. Okay, so there's like level weekly, the lowest one, and then we have this release, and then we have LTS. So we have weekly and LTS, and weekly increments by one every week, right? So here's a diagram that may help. So weekly increments by one every week, right? And over a 12-week cycle, I wonder why it shows the number as 24, oh, right. Over a 12-week quarter, we released the old version, 2.303.3. Two weeks later, we released the release candidate of the new version, 2.319.1. Four weeks later, we released the .1. So that was just yesterday. Yes. Two weeks after that, we'll do a release candidate of .2. So 2.319.2's release candidate will happen about the 15th of December. And then the release, based on current schedule, would happen the 29th of December. Now, 29 December for many people in the Jenkins Project is right in the middle of our end of year holidays. And so we'll probably shift it one week later. But the pattern generally applies. Then two weeks later, we prepare the release candidate for 319.3 and we choose the baseline for the next version. So, let's see, we're at 23, so 25, 27, 29, 31. So probably 2.332 or 2.333 will be chosen here as the baseline for the next release, which will happen here. Makes sense. Right. So, since most of our time will be spent on this and I wanted to ask another question on this, we just worked on this X.1 yesterday, right? Yes. Yes. So, if I want to help you on X.2 ReleaseCycle, ReleaseCandidate, how should I be, which VTT block should I be monitoring for that? Yeah, so the Jenkins developer list will announce X.2 ReleaseCandidate. And it will, in the announcement to it, it will say, someone will say, I am willing to be the release lead and they will propose which thing should be backported to it. And those backports actually are marked in the Jenkins Jira system. I'm gonna move this off screen just temporarily, just a minute while I go to find this on Jira. There's some sensitive things in my Jira that I have to be sure we don't show. Okay, so now let's see. So, we are looking for issues, LTS candidates. Here we go, yes. All right, so I just did a query that asks for show me all the bugs that are labeled as candidates for the long-term support release. Right now we have just one, this bug, and it's been labeled LTS candidate here. So, this one is to be considered and it was chosen intentionally not to include it at 2.3.19.1. So, this 2.319.1-rejected says, we chose not to include it. It was too new to include it in 319.1. So, we will wait four weeks and then include it in .2, most likely, giving it more time to be tested, more time to be verified that it's good and okay for LTS. So, who labeled this the person who asked you to work on it? Right, so Vincent Latomba submitted it and said, I think this is worthy of being an LTS candidate. This is significant and others may do it as well. There have been times where I've labeled a bug as LTS candidate even though I wasn't the submitter. Okay, so you labeled the candidate, LTS candidate to some bugs and those will be put in the next release. Yeah, then the release lead looks at that list of bugs and says, ah, here are the proposals and they propose a backporting pull request and the backporting pull request looks like this. Right, that's where it's Jenkins GitHub Core. Is that the Cathy one? It is, yes. It's the backporting pull request that Cathy Chan did. Yes, very good. Yes, so feel like it. I was trying to understand that as well, didn't get it that time. Yeah, so here it is. So this is the backporting pull request from Cathy Chan. So these are the LTS candidates that she picked out. That's correct. Okay, and then what did you do with all of these? Candidates. Yeah, so let's go look at one and we'll go look at its history so you can see the transitions that it went through. So we're going to switch and look at this one. Okay, so this is build history is missing a hyperlink. If we look down here at its history, what we'll see is I created the issue 1st of November. I updated the description, et cetera, changed the status to open in progress. Daniel Beck labeled it as an LTS candidate. He said, this is serious enough. It needs to be an LTS candidate and or he labeled, no, I labeled it as an LTS candidate. He said, not only is it an LTS candidate, it is also a regression and he's right, it was. And he corrected it instead of being a task. It's a bug. Then when it was fixed in weekly, so a pull request was submitted. So I marked it as in review. Then it was fixed when it was merged into Jenkins. Then it was moved to closed when 2.320 was released. So this bug is in weekly between 2.314 and 2.319 and then it's fixed is merged into 2.320 and the bug is closed. So at this point in time, the bug is closed but still has the label LTS candidate. Kathy finds it and says, oh, it's closed and has LTS candidate, therefore it's a candidate. She proposes it and when she proposes it, she changes the label to add this fixed label to it to say this thing is ready and will be fixed in 2.319 stable. Right, make sense. So the LTS candidates which are closed or which are fixed, they would be selected. Correct, that's right. In order, we generally will not take a change into LTS that hasn't already been used in weekly and we would prefer has had some time being tested in weekly. Right, okay. So what would be my responsibility next time? If there's a release candidate and they have done their work of picking out all the LTS candidate entries and they have created this full request that you showed me that Kathy did. So what would be my job here? Yeah, so then what you do is you take that list, so this list of backports and you propose a pull request to the LTS change log that includes the entries from weekly for each of the things that was included in the LTS in this proposed backport. So that's, did that mean to read that? Yes, so there is this bug 67063 was detected and big enough, we wanted to fix it by backporting. I went and found the weekly change log entry for exactly this bug and copied it into the LTS change log and you would do the same thing. Okay. And now there is actually a script that can help with this, but I've found that I can as easily copy the text as I can do anything with a script. Right, that makes sense. Okay. Yes, so we're already past one minute. Yeah, so, and I confess I'm at a point where I need to actually copy the text at a point where I need to actually get a little bit of rest. I'm not nearly as young and vigorous as you are. I've got a presentation that I'll be doing. So I'd propose we stop here and call this good enough. Dheeraj, thank you for joining. We'll talk more about the next segment in our Tuesday meeting, if that's okay. That would be really great. I'm sorry if I bothered you with so many questions. Oh, thank you for the questions. That's exceptional, thank you very much. Have a great evening, sleep well. Bye bye, Ethan. Bye bye.