 First for the Jenkins project is the 21st of June or 22nd of June, India standard time. Great to have every have you here. For right now it's just dirage and me and I've got these topics weekly release change log 289 200 to 289.2 LTS change log, and we hope the bulk of the session will be on the contributors on it. Anything else dirage that you want to add to the agenda. No, nothing from my side. Okay, well so shall we go to weekly release change log first I, I'm really pleased to see that Tim have you seen Tim Jack Holmes work on automation. I think he started yesterday. If I'm wrong. Yeah, so, so at least now there's, there's, I don't know that it's going to be ready to actually run this week. So, so I think we still need a change like this week, or do you know differently and hey there is already a change log available. Well, for this week, but this week I tried to generate the change log and I was a good but then I had a power. So everything is done, but I need to just push it to me. Oh okay so you've got the you've got the change log written. All right. Ready to push it okay we're great so is there anything else that you and I mark to review the poll request from Tim. For change log automation. And, and he specifically requested my review I'm not sure I'm credible but I'm happy to review it and try to be useful. Right. So, if it's not a problem for you then can you like run the automated change log tool and see how many entries are there just to cross it if I have the same amount of entries or not. Oh, good. Okay. Yeah. Or else, and I can also share my screen if you want, I can show you the draft. No need if you push if you push the poll request I'll review it in the poll request. That's great. After that one more question about how the docker tool change log tool. Extracts the pull request from Jenkins repository to the, the change log.yaml file for us. So I wanted to know which pull request goes to the comment section and which does not. So there are some tags right so I wanted to have some discussion on that as well. Okay, a so yeah so my understanding is that the way that a pull request is decided if it should not be included in the change log is there's a tag skip dash change log. So let's take a look at, for instance, this one. Tim assigned this label skip dash change log. And that will cause it to be written into the change log as a comment, whereas this one does not have skip dash change log so it would by default, tend to be written into it now I'm going to actually label it skip change log, because this particular one I don't think justifies an entry for the user. This is an entirely internal to the test the automated testing of Jenkins. Jenkins users don't need to see that. Does that make sense. Yes, it does. So all the pieces that are open that will not be taken up by the change lock to all those have been closed that will be taken up. That's correct is certainly only the ones that have been closed and or are merged actually I guess is the is the more precise term. And if they've been merged and have skip change log, then they'll be in the comment. If they've if they don't have skip change log. I don't know if I can do that. No, it doesn't do negation. Without skip change log like, well, like, let's see, like this one. And somehow I think that oh this was just closed okay that's why that's not a problem this was not merged. We wanted one that was merged. So like this one. Nope, it's also got skipped. Any of them. Okay, here we go implement intercepting executor surface without Java without Guava. This one has been merged and should be in a in one of the change logs. And while you're at it, can you go back to that here. Sure. And can you go to the proposed change log. Yes, this one. So I have, I have put and placed this similar text as the change log entry. Is that correct in terms of verb and everything. It is yes, that's correct. Just have changed the code that just to highlight it. Right this this text this text is exactly what should be in the in the change lock that's correct. Okay. So I understood. All right. Yeah, so I think. Yeah that that's an interesting one because this is this particular library Guava has been filled with challenges for us and we we want to decrease our usage of Guava wherever we can but in this case the class hierarchy includes guava, guava objects in the signatures. And therefore doing it without guava really does mean making changes to class hierarchy. And so that's, that's the worry there that this is a this is a very, a very cool change. Yep. All right so change. Change log entry to be skipped. Anything else on the weekly release change log. I'll push the changes. Excellent super thank you. Okay then I propose let's switch. And let's go to the 2.289.2 LTS change log. We had planned to do that are you okay if we take the time to tonight today to do that. Definitely as I was waiting for this. Okay great well and and so the documentation for how to do this is is inside the. Jenkins. Change log generator, which I thought it was here. No, not there. Oh well that would have done it. Here we'll just use that it's taking us here because that's the repository that has the tool in it. So in core change log generator. I believe there is instruction yeah here we go. It's got these are the things that we can use for all the back ported issues. And yeah, so let's let's see if we can work through it so I don't I haven't used. Well, let's see if this this is the if the technique would work. Because I have to go remind myself each time so let's go look at Jenkins Jira. I'm going to stop sharing for just a minute while I bring up Jira. Okay, now. And I want to find all issues that are flag two dot to 89.2 dash fixed. No, that's not it. Okay, here we go. Good. All right so back to sharing my screen again here comes. All right so what you should see here are items that have had the label assigned to them to dot to 89.2 dash fixed. And these should be the same things that are mentioned in Jenkins core in the pull request that merges to dot to 89.2. Let's see these be closed back porting for two dot to 89.2. So we should see 65766, which we do and 65751 and 65657, which we do and 624, which we do and. So, so this and this match seem to match each other showing us which things have been back ported from 2.289 or from later releases and 2.289 into 289.2. Any questions so far. So the PRs that we want to find out in the main core repository, they will be in a particular merge which we labeled as back porting for and then the version number. Actually, I think the label here is this into LTS label. Look at that I think usually, yeah that the title of the PR is back porting for but then the label is into dash LTS. Okay, so it's better to remember it by the label. Right, so yeah but so you were you were very, very good so so here is we see this one back porting for LTS 2.289.1 and then before 2.289.1 released. An additional back port. And here is the one for 2.289.2 and, and we see it here with this block of text. All right, now this one. It will help me if I. Here's I'm not allowed to edit. Okay, I'm going to do an edit here just because I don't need that. We just need it to say 2.296. Is that correct. I think that's correct. And now we don't have the horizontal scroll bar and we've got the information so this column here shows us which version included the fix first included the fix. This one I'm not sure what to think about that extra 2.289.1 will have to investigate that further. And this one. I don't know which version included those two so let's do some quick checking here. 64347 included in which release. So if we look at the commit sometimes we're lucky enough that it will show us the tag that first included that commit. Nope, I don't see it there. Okay, so let's look at the change log to see where it mentions that I remember doing this on 2.297 or 296. Yes, there it is 297 good okay so Jenkins 2.297 is the one that includes that 64347. Okay, and 65195 is also 2.297. Okay, good. So I think we've got recorded which version each of them was done in good. All right. Okay, LTS backports change log. Okay. Okay, so here is the script. I don't run it very often. So let's try it. Sorry just checking to be sure that everything is correct and complete here. Yep, there are the mentions of them. Good. And I think what it says we've run it like that oops wrong argument number. 2.289.2 and path to Jenkins.io content like that new invalid numeric literal at line one column seven. That did not help me very much. I am not a Ruby programmer so we may end up doing this. Sort of the hard way. And the hard way is actually not that hard so I don't feel too badly about it. Just a minute. I'm just going to do this one for right now. Just a moment, we're going to use that one, because I think this may give us similar results. So it gives us fixed request submit usage. Fix process tree stop using deprecated submit events. I think this gave us a good working copy. So I'm going to check out change log dash 2.289.2 start this run and while we're here. Okay, content underscore data change logs weekly. No, no, no, we need LTS don't we. It is good. Okay, so we've got the right thing. So my technique is just this one. I'm going to use the steel one that's already there nine dot two, and we need the release date for that, which is, I believe, June 30. And now we need the changes. So I don't carry comments. There is a rough draft. Now what I'm going to do is let's look at the list in the order that Tim provided them to 65766. Are they in all those are just in numerical order so probably not what users will expect. Okay, so, but to be sure we get the right things let's in numerical order initially, so that we know we've got an exact match okay 6576665751 657, after 657, then 65624. So I apologize if this is boring. Okay, no wait a second 62465624, not included what okay webhook failures. Okay that surprises me. So this one is not found. Why not have hook failures. That's not mentioned in any of our change logs. Alright, so I need to go find this one. I don't understand that. So webhook failures. Why would I be missing that one dirage any insights. 65624 is not mentioned in this one either. Only mentioned there. And yet it says it was included in 2.290. Okay, more research. Okay, here's the poll request. Okay. Oh, he says the related poll request was not 940 40. Okay, so what happened was the upgrade. Is this saying that the upgrade to. Oh, okay the upgrade to 9.4 39 did harm. This one switch to Winston five that's at 17 updates us to 9.4 40. Okay, good. What I need to find is the this one is in fact the Winston upgrade. That's why I'm not finding it. It's this one right here. Okay, so that explains why it's not included. Oh, but there it is. It went one step further. Okay. Whoops, that that was not what I wanted. Because we've got Winston five dot 17th. Okay, here I understand. Alright, so, so dirage what's happened here is this this message this problem. The upgraded of jetty to nine dot four dot 39 caused a problem. It was solved in this backport by upgrading to Winston five dot 18 which includes and the newer version of jetty to fix the problem. So now if we look at this change we should see it. There it is. So this is the change. But now I understand at least and therefore this thing right here. This mention of Winston five dot 18 is the upgrade but it's doing an update of jetty from not just nine four dot 40. I think actually going from Winston five 16. Where do we see that. I was just looking at that where was it all right here. No, right here. Okay, this is going from Winston five dot 16 to five dot 18, which means we have to document two steps in this change. So we have to describe not just the update. We're updating Winston five dot seven dot 17. So we're upgrading from wins to Winston five dot 18 update jetty from, and now it's going through two versions. So we have to describe the two versions not just the one. There it is, like that. Okay, because this is saying we're going from Winston five dot 17. And fight we're installing five that's updating from five dot 16 to five dot 18 so Winston. Now it's nine dot four dot 39 something. Sorry that this is so complicated. I fear that we may have to schedule a second session for our, our work on the on the slides. Are you okay with me continuing with this still. Yes, yes. That's not a problem. Okay, so what we find here is update jetty from nine. Okay. Okay, so what we have here is, and we decided this goes right after 65657. Then 65585. It is. And it's in the correct location. Good. 64911. It is 665195. Okay, we did that one. Oh, 64991. Okay. There it is. And it's in the correct location. 64347. There it is as well. Again, correct location. 65195. Okay, there it is. And then this one is just the back porting one so it can be deleted. All right. Now, I think I'm ready to double check the list. So 65766. There, got it. 65751. Got it. 65657. Got it. This one is. Oh, we lost the bug report for this one we need to put the bug report in here. And what was the bug report number it was 65624. All that work collecting that then for me to drop it 65624. Okay, now 65585. Yep. 64991. Yes. 65195. Oh, 64347. Whoops, where 64347. What did I do. It's in the same thing. Okay, got it. So, okay, that's good. So covered. 65195, which is. Right here and we've got one extra 53462. Okay, I don't know what to think about this last one. Did I make a mistake gathering that in. Pull request 5405. Okay, this one. 289.1 289.2 RC. Okay, so this is intended to be included. And these commits will be included. But it was already mentioned in the 2.289.1 change log right. Yeah, there it is. It's already mentioned so we don't need to mention it a second time. Okay, I don't know how I got that in there, but there really isn't a particular change. Well, is there. Okay, this one has been particularly challenging. Because there are things involved here. With multiple attempts to fix the thing, but this change is in this specific pull request was already in 2.289.1 according to this. Since it's already there, I don't see why we would mention it. This one is a place to put in as a comment. So after 2.289.1, they did some more changes on this. You're saying we don't need to mention it again and latest one. Yeah, and so there were there was an additional pull request right. Okay, so I'm just going to, I'm going to steal a, I'm just going to take a moment to add something to the chat. So how do we insert a comment? Because I don't think we want this in the LTS change log, but just to show that you and I thought about it. Let's put it here. Do you think, does that seem reasonable? Yes. I mean, it truly has already been mentioned, and if we look for 50405. Oh, wait a sec. No, we look for. It has been mentioned multiple times. So I think it's reasonable for us to include the mention there. All right, now let's do the actual content editing of this. Okay, so, so. So what we have done till now is we extracted all the PRs for the type of the change lock tool and then we placed it in the right file and then we ordered them according to their number and now we are formatting their message. Correct, exactly. Yeah, very good observation. Yeah, so I'm formatting them. I think then we will need to go back and revisit the ordering to get the ordering correct for user benefit, but exactly. So I wanted to be sure that I didn't miss anything in creating the change log. So I went through it in the order that they were referenced in the poll request. Yeah, exactly. Understood, please. I'm doing, okay, so poll request is 54.98. Issue is this, date here is to 17. And this is the Winstone one that we did in some depth. Let's compare Winstone. So the way it's been formatted in the past has been just to declare Winstone without using the version number. So let's do that again. Winstone 5.18, update Jetty from something, something for bug fixes and enhancements. And one of the bug fixes is this issue 65.624. All right, so then we've got major bug regression, proposed change logs 65.5, okay, that's good. Regressions in form submissions after. Now we need poll request. So we need a references section. An issue of poll on a poll. Issue is this one, this one, this one. Regression in 2.289.1, I think. Or no, was this, okay. Now I gotta go do the research just a moment because I need to see which one this is. What version did this first regress in? So it was fixed in 2.289.2-fixed. So I believe it regressed. Okay, it was released in 2.296. So it had to be a problem already in 2.289.1. At least I think it was, right? Because, so the regression came at least in 2.289.1. The question then is, did it last longer than even that caused by this and this change was first merged into, okay, the first version that had this one was Jenkins 2.28, okay. So the first version with this regression really was as far as we know, 2.289.1. Okay, good. So where is that? There we go, okay. Like that, okay. Any objections so far, Dirage? Okay, all right, now another one. This one is redirect users to the previous page. Okay, it's a comment from Daniel. We're just gonna leave it. I like it. Okay, this one says fixes to process tree implementation in Darwin. While writing in, while including this in weekly change law, Olex has to create two entries for both of the Jenkins issues. Very good, okay. And that's what I was assuming. So that's excellent. So his recommendation was this should be two entries. Is that right? Yes, yes. Okay, good. And so let's, and I bet you already did that in the weekly, didn't you? Yes. So we can just steal your weekly text 347. So here is the weekly, right? And now we have to fix the indentation on this one. Whoops, where'd it go? More space to work. Okay, so here's the out of bounds memory access on, and these, they are right next to each other. So we can just grab them both. Perfect, thank you, Dirage. So glad that you're here. Okay, so now this needs to be indented to match the current file format. I think we can undo the tabs by pressing, selecting the text and then pressing shift and tab. Yeah, I'm not sure that my Emacs has that setup. Okay, so you're saying that VS code would have allowed me to do that re-indent very trivially? Yes, in the backward direction. So let's just do this. Okay, now I think we are ready. Okay, bug, bug. Yeah, so there they are, the two express separately just as they're done in the weekly. All right, now let's get the ordering right. I think the rules were RFEs before bugs, right? And major before non-major. Yes. So there's a major. Okay, so RFE, RFE, bug, bug, bug, bug. All right, those are all at least bugs. So let's try building the page and see what happens. So poor little computer has been very busy while I've been editing. Now we're going to open up that page. I had forgotten to do the force thing. Now let's see if it worked. Okay, here's what we've got. Let's read it together. See if we believe this makes any sense. So we've got major fix, update extreme. Okay, I think we should put this one before this one because there is an important fix inside that one. What do you think? Yes. This one is closer to being mechanical. Okay, so winstone 5.18, update from a race conditioning class loading, do not change fonts. Okay, any objection from you? Not on this, I just have some few questions. Okay. I'll ask them very quickly as we know the time is there. So what is the frequency of these NDS change logs? Every four weeks. Every four weeks. And when is the, okay, so when should a person write the change log for NDS? Roughly two weeks between what, the preference is two weeks prior to the release. So what happens is the calendar, let's look at the Jenkins calendar. We'll just drag in my calendar. The Jenkins calendar shows us that June 30th is the 2.289.2 release. And our preference would be two weeks before the release candidate is delivered. And shortly after that release candidate being delivered is when we would like the change log and the upgrade guide. So after 16, there may be some more changes that have to be included in the NDS change log. So that will be done side by side, right? There might be, but it is quite rare that there are changes after the initial release candidate because the team that the release lead will take quite a bit of effort to try to be sure to have all of the changes that were desired into it in time for the release candidate. So that those of us who test the release candidate don't have to discard our test environments and start again. Right. And which change ideally goes into weekly and which one goes to LTS? Okay, now I'm not sure, ask that question again. Which change goes into weekly and which change goes into LTS? Explain further. Yes, so there are some changes which I have to add in the weekly change log. And there are some changes that are added into the LTS change logs. So I was thinking that all the weekly change log that fall in the four week time limit will go into the LTS change logs, but that is not the case. So how do we decide? Right, good question. Okay, so in choosing which things go into an LTS change log, particularly the dot one. So 2.289.1, that's a judgment call from the author of the change log to decide which things deserved to be mentioned and which do not. Right. And you also showed me earlier previously in the meeting that there is a upgrading document that is written by a dedicated author on the Jenkins IO website for LTS change log. So what about that? That's a very good one and that was the next thing we need to do. So let's go look at that. If we look in the upgrades directory, we'll now find a 289.1 ADOC and we're going to create a new one called 2.289.2.ADOC. And now when I looked, as we were looking through all those changes, I didn't see anything that seemed like it justified a change log. So I would just by default copy this text into the 2.289.2 change log Now let's go back and let's look together just to be sure that we didn't lose something there. Let's see what we've got. Okay, so back to the LTS change log. Okay, are there any of these things that would require an upgrade guide entry? This one does not. The user just gets it, it's fixed. This one, there's no change they need to make for configuration even with that issue. That is just the failure should no longer happen. Likewise, this one nothing and these, this one nothing, nothing. Yeah, so this one I think it is correct for it to declare no notable changes requiring upgrade notes. Did that answer your question? Yes. Okay, let's take a look and see what we've got changed then. So here we've got this one. We need to register that with SCM. And here we've got this one and this one we need to check its differences just to see what's changed. Whoops, this is okay. All right, so what we have here is 2.289.2 change log delivering this 30th of June with these changes in it. Dear Ash, I think we're ready to call that good. So I'm going to go ahead and commit those two things. Add 2.289.2 change log and upgrade guide. Okay, all right, so we've done that. Now we should be ready to create the pull requests. Whoops, wait a second. It says there's an, oh, okay, let's try that again. GHPR create, we should push it to my branch. Okay, submitting it. And now we need to go place this screenshot. Sorry, this is again a rather complicated thing but in order to make it easier for people to read the changes. We always post a screenshot but I guess you've done this from weekly so you know all about this, right? Yeah, okay, good. So here is the screenshot of that one and there we go. So I just, small three more questions as well. Okay. So can LTS change log be also automated or cannot be? I think eventually it could be if we were to use some better labeling. It's just a minute actually, this is good. Let me, so. I can ask you later. Oh, no, no, no, quite the opposite. I think this question that I just received may allow me even more time, may allow time for you and I to continue what we're doing because I don't have the next meeting. Okay, good. Sorry, forgive the interruption, Dheeraj. That was, I just needed to handle something with Google Summer of Code. Okay, so we've done, now back to your question. Ask your question again and let me focus. Yes, about the automation of LTS change logs. So I think it very well could be possible and Oleg believed it was possible. It's a much heavier curation process, much heavier review process for the LTS change log than it is for any other change, for the weekly change log. But the things that you and I just did, right? Reviewing these things, applying the text transformations, et cetera, those could probably be done with labels or greatly improved with labels if people were willing to apply labels and do similar techniques to the poll requests as they were developing. Also depends upon if they do that or not, right? I think so because we've up to this point at least chosen to make the LTS change log, something that we intend to be read by users and for them to think carefully about what they're reading. And in order to do that, it has thus far anyway, needed to be, it has needed for us to be more careful in what we include in it. It has to be human reviewed. Okay. And I also went to another website of someone, another thing. So they have changed logs and I clicked on it and they redirect me to the data repository having all the changes. But in case we have a dedicated place where the developers can view the change logs and it is for their convenience and specific order style guides just follow. So this is just to help the developers, right? Let less time is spent on this side to the other side. Well, so the Jenkins also likes the GitHub releases concept, right? So we use, we also are quite happy to use, I think what you're referring to, and it is something like this where when I look at this through GitHub, it tells me, oh, here are the new features and improvements in 298, here are the dependency updates. Is that what you were referring to? Yes. And also Jenkins.io website, go ahead. Yes. Also the Jenkins.io website, we have a separate page for change logs so that they can view all of them. So that is also something to help developers to look at, yes. You mean like this? Yes. Yes, so well, this one actually is focused on end users more than it is even on developers. Yes, we allow that, we frequently place developer content there, but the first focus for this one is still on users rather than on just developers. Especially be, go ahead. Because some websites don't even have this page dedicated for change logs. So this is an extra step taken by Jenkins, right? Correct. Well, and this is an extra step taken by Jenkins that also allows us to gather data from users when they click one of these three icons. So if the user clicks 48 here, Jenkins.io says thanks and the number goes up to 49. That says I successfully deployed 2.298. If I had an issue, I experienced notable issues, I can click this one and it will prompt me for the issue number from JIRA. Now I didn't, so and likewise for this one, if I had to roll back, I can enter that and then it will remember those issue numbers here so that others can see, oh, here's the things that the community reported were problems. Got it. And the last, I think the next question is that the previous to previous DOX Office R video apparently on the YouTube channel had a surprising lot of views. It has 40 views. So I'm just wondering why does it have so many views? Do you know? Sorry, which thing had 40 views? The, I think previous to previous DOX Office R video. Ah, I don't know. That's a good question. Let's go, all I can do is make guesses on that one. That's a very, very good one because what we have here is I can open it up and show you, we've got, let's switch. I'll switch to the Jenkins account. And now we're going to look at the playlists, Jenkins playlists. I just hope I have not shared something that I should not be sharing on screen. Oh, well, and that's okay, right? If you have, you let me know and we'll delete that video. If you discover, oh, there was something sensitive that I had shown, then we delete that video, that there's no shame in us saying, oops, we didn't intend to show that. So, where are the playlists here? Okay, so we want to see the DOX SIG. Okay, and so for example, yeah, here is, and you said that one of these had a recent one had, so like our session from last week had 40 views. No, not this one. Okay, this one had 12. Previous, okay. This one has seven. Previous. This one is 41, wow. Okay, apparently we are very popular. I would never have guessed that 41 views of, I don't know how we might change those, I don't know. Apparently, I don't have any answer as to why that one would have been so popular. Are any of the others as popular as that? No, 10 views, okay. So, that's very interesting. I wonder what, well, let's, maybe there's something to be learned from that. What does this, and I'll see that doesn't, sometimes I put much longer comments here, but didn't on this one. So, since it's not got even a longer comment, I can't explain why this one got 40 views. No problem. I'll look at it and let you know if I can find something. Okay. And I'm gonna switch back. All right. Go ahead. Yes. Just last thing I wanted to share is that the weekly PR that I'm supposed to push to the main four, I think it will be delayed because I have something else going on. So, it will be delayed by five to six hours if that's not an issue for you. That is not an issue. If it's not available exactly at the time that it built, if it's only five or six hours from now, you'll be available in plenty of time. I won't review it because I'll be asleep, but others can review it and decide if there are changes needed. Sure. So, I'll be pushing it after six hours, so that would not be a problem. Great. That's wonderful. And if we need to end immediately, we could end immediately. If you've got 10 or 15 minutes to talk about our session at the contributor summit, I would love to spend a few minutes on that. Or do you need, are the things you need to do for university or for personal needs? We could stop right now, Dheeraj, if needed. Yes, actually I do have one important thing. Okay, so let's call this an end and we will talk. I may send you an invitation to talk about the contributor summit separately. Aditya also couldn't join us, so it probably would be good for us to meet together separately to talk about it anyway. Exactly. So that's before the CDCon, right? It is. So well, the contributor summit is Friday or Saturday morning your time. And so it will be, we've got a few days still that we can meet together to talk further. Right, that would be great. All right, thanks very much. I'll stop our recording. You have a great day. Good luck, thank you. Thank you so much.