 Welcome. This is Jenkins documentation office hours. It's the 28th of June, or if you're in India Standard Time, it's the 29th of June. Grateful that you're here. Thanks very much. Agenda topics that I have include Jenkins security releases that are coming and the impact that has on the weekly changelog and the LTS changelog. And then contribute your summit retrospective. And what other topics do you like to include on the agenda? Nothing from my side. Okay. All right. Okay, well then let's one that was on my mind. I'm not sure we'll get to it, but it would be. I would love to have a chance to talk about the use cases. And double check, compared to the pull request. And the four of the four of us are probably as good a set of people to briefly discuss those use cases as as we're going to get. Okay, so Jenkins security release we're on. So let's let's know what that means so no Tuesday weekly release this week. I've already paused. Awaiting the security release. Sorry, I've got my volume a little too low. Dear, what was that. I actually submitted a PR for I just submitted a PR, half an hour ago. Okay, no, no harm. That's that's great. PR was submitted, but will be ignored. Yeah, that no no problem this is a this is the first time you've encountered a security release and so that's I and I confess every time we have a security release they aren't that frequent thankfully every time we have a release of Jenkins core for security. I have to be reminded what it means and why why it means that why we do it that way. And it's a good thing for release management from release management perspective to understand why things are done the way they are. Okay, so. So the release job is blocked. It's disabled. The weekly release job is disabled. Awaiting the security release. The security team will build Jenkins 2.300 themselves. On a separate branch. And the reason they on a private branch they redo that because if they do it publicly, they could disclose prevents disclosing the breach disclosing the vulnerability prematurely. So they build privately. All right so and it's probably by this point already built. It is intense intentionally 2.2 99 plus only the security fixes. So no other changes than security fixes in the weekly, and that's in order to reduce the risk to weekly users of unrelated changes, it would be terrible if we it would be a bad experience for the user if we received an unrelated change in the weekly that broke them and they were stuck with either having something that had a known security vulnerability, or something that was broken. And so in this case, the better choice is 2.300 will be just 2.2 99 plus security fixes. And that means the weekly release changelog. That's why the weekly weekly release changelog. So, Deraj, what I'd suggest is for your convenience go ahead and close the PR. Because when we do, because the next weekly will have a much larger, a larger set of changes right it will have two weeks of change two weeks worth of changes. So we may have to do some special effort on that one to assure that we get no no no actually we won't because the tool the tool will because of this change 2.99 plus only security fixes and on a private branch. What you'll see in the branch history is all the changes that were included in this poll in this week's proposed poll request that one will still be visible next week as being proposed into 2.301. Any questions so far Deraj or Meg or Kristen. Nope, very interesting. Yeah, so so now let's talk about the LTS changelog because it's different. And it's different because the back ported fixes for 2.289.2 are included in the security in 2.289.2 security release. And that's because back ports are more thoroughly vetted then changes to weekly and are intentionally chosen to resolve known issues. One of the concerns I have is that the the docs, the changelog PR has not been merged. And I need to check with Daniel Beck with the security team tomorrow to see if it should be merged. Or if they prefer to be the ones who merged it because what they will do the security team will combine will create the 2.289.2 final changelog, and it will be the current PR, plus the security fixes. Any questions there, then let's go with. Next topic so Jenkins contributor summit retrospective. Let's see so first test. Dear Raj, I know you attended because you were a presenter. Meg, did you get a chance to attend it was a terribly early hour of the day for you so I assume you probably did not. And you're muted Meg. Sorry, no and I did not I'm just hammered with some other stuff right now. No problem. And Kristen I assume likewise for you that you probably. I was not able to go because my day job has been taking up a lot of time. Which is really good because they pay you for your day job. That's that's that's how it's supposed to be actually so yeah we should not be complaining that we get paid to do our day job that's that's wonderful. So dear Raj. What I was thinking is let you and I go through. I would love to hear your feedback on the experience and collect it, or if you want you could enter it into the document yourself hang on just a minute and let me find the document, and we'll bring it up. Just a moment. So for Meg for you and for for Kristen, we had some awkward and very frustrating technical difficulties because I didn't test the setup well enough before we started it. But well mistakes happen and in this case mistakes really happened. And they were my fault and that's awkward and embarrassing but okay we survived. Oh leg made it a great, great session, even with my mistakes. What a team. Yeah. All right. So let's take a where is the original. Oh, I know, just a minute. Sorry, still looking for it. I need to get the real document. So retrospective link goes here. And then I'm just going to drag it in and let's look at it together. Okay, so retrospective here was. Yeah. Okay, so what went well. Dear Raj. And Aditya presented segments in the newcomers track. Thank you very much dear Raj. That was absolutely wonderful. You were audible your presentation was well received you contributed to the other segment other portions of the segment of the segment of the track, offered suggestions to the attendees. And it worked great. Any concerns from you other than okay it was a let's see on the what could we do better I'm going to put one here. No, no. Dear Raj Joda. Next summit in the APAC in the APAC time zone. Same thing so dear Raj was up at what midnight and from midnight to two or 3am. It started here at 730pm and ended around 1030pm to 11pm. Yeah, so very good so heroic beyond words to be on a Friday night at 730pm instead of being out enjoying yourself doing something you were sitting helping with a presentation. Yes, excellent. Okay, so what else could we do better. Yeah, so. What else about you can, if it's possible you can improve the timing for Indian time zone. Right, and that, and Oleg's agreed with that he says do the next summit in APAC time zone. Absolutely we, he presented a talk at a conference with sink its university, and the day, the Monday following and had 500 attendees from there in India so yeah, absolutely there's a lot of interest in open source. So good, because towards the end of the summit I was, I was trying to have my dinner as well. Yeah, well, and Oleg went like seven or eight hours without food through that whole thing so same same thing right which is a good one it's we ought to put a note in W test the zoom setup. Before the summit to assure the parts and pieces work together broke the zoom webinar stopped to the zoom I stopped the zoom webinar by starting another meeting for everyone by starting another meeting, configure the breakout sessions. The meeting. Oleg had to configure them during the meeting. Any other comments dirage things that you think we should do better. I really love everything. So there's nothing from my side. Okay. Yeah, I think actually one of the things I'd like to put on the went well is. And Aditya, actively participated in the preparation in preparation and presentation. Yeah. Discussed improved. Okay. People that joined us. So is this is this normal. It's a much smaller set than we expected. As Oleg notes here that the first problem was we, the communication channel we use to announce the zoom link ended up arrived in many people spam inbox. And so we need to use Jenkins online meetup. And social media to announce the webinar location URL. The webinar is not susceptible to zoom bombs, zoom bomb attacks. But we need to we, we didn't share it widely enough so. This is a good point because even I was trying to search the link for new commerce track and exactly. And, and we had many people who were presenters who at the time the meeting was supposed to start still didn't have the link so that was that was a major mistake on my part that we, we shouldn't let happen again. Absolutely. Yeah, actually I guess what I should note is the zoom webinar portion worked well enough. Yeah. Reliable, consistent, etc. Single person advancing slides worked well also. Those are all the topics I had, do you ask anything else from you. The way you explain the development and adopting section was really nice. Oh good. Yeah, okay. It also convinced me to adopt a plugin. Good. Fewer attendees we we had from from what it was as few as as many as I think six attendees at the start. So three presenters, six attendees at the start to three attendees by the end. And the reason was students in India. Dropped off to attend to attend workshop to other tracks, right and that's perfectly reasonable we knew that would happen. And it was G sox students I think if I remember right. But that was, that was a smaller group it made it it made it a lot of fun actually to have a conversation with those three people about their various experiences actually and that's a positive wide range of experience of experience and engagement for three people. Exactly. That was a great discussion. We had one Kubernetes user fully automated one maintainer of an ancient plug in ancient plug in on older environments, and then one between the two. For me at least that was a really fun conversation because we got to talk about plug in installation manager. Managing installations in general managing installs with configuration as code. That was actually for me pretty cool dirage when you shared your blog experience. Sure, so here we've got people who've been using Jenkins for years and the student who just started in. Was it February or March that you first started experimenting with Jenkins and you were saying oh yeah and here's what I learned in this I did this yeah so. Yes. It's all because of you. Right right that's what it was it's not that you did a bunch of hard work to figure to learn jcasc. Yeah, that's that was great well done very very well done. Yes, I got a lot of help from you. All right, so I think that covered the topics I had anything else for retrospective. So one thing I want to discuss is why do students. There's a little less contributions coming from beginner students. So is it because the thing is very complex or something like that. Good question. So let's let's I think that's a, that's a good one. Is it perceived as too complex. Is it, is it unknown to them as a, as a unknown to them as a component as a tool. I have many of the students at the universities here in the US at least don't don't commonly hear about continuous integration as a concept at least they hadn't when I was checking not long ago. What's your experience there at your university in India, do they teach the concept of continuous integration or how to how to test your code more thoroughly. No, not at all. And one of the things that I've seen mentioned in in the Jenkins in the Jenkins outreach group is that they're considering ways how do we reach into universities more effectively because Hoffner is a member of the Jenkins governance board and a professor at a German university, and he teaches courses using Jenkins development as the lab exercises. And so the students are developing Jenkins plugins as part of their part of their work. So to teach testing concepts to teach JavaScript. He does all sorts of different test teaching with Jenkins as the as the component. That is very good. Good question. Any other questions you want to or other observations. Okay. We're going to go into universities. It's, it's difficult, right. We cannot like, ask the university to introduce a curriculum there. Right, that's a problem right. Right well and, and Jenkins as an open source project is not going to spend 10s of 1000 of dollars to develop curriculum materials that a university professor could do use right that's, we just don't have the funds to do that and therefore, think about, okay, what would it mean for us to try to reach to a university. And how could we, how could we reach them without needing to spend 10s of 1000s of dollars to develop coursework that they would then teach. So back to so see the notes we inserted there. Great. Okay, so next topic and this one I suspect we need all of our, all of our voices together is plugin installation manager tool use cases. So the reason I'm asking is there is an open pull request here in J on Jenkins.io for the plugin installation manager tool and where is it this one. And one of my concerns is I'm not sure we've got all the use cases covered and the use cases I've reviewed. I was, oh, is that that the right thing so what I was going to propose is let's go through this and extract the use cases quickly and then discuss and here I can probably do it this way. So what I'm going to do is grab this pull request. And let's find. Okay, so here is this one. Sorry, one quick change. Okay, check out the PR. Okay, merge the master branch so it's up to date. Okay, and this is the one we want. What I was going to do is grab the headings. So here are the use cases and let's talk to those, which have we missed in working with plugin installation manager. Okay, so back here. Generate the list of plugins installed seems reasonable. List string listing plugin dependencies. And I assume actually we probably want non jaren form right preview the installation of plugins install a plugin. Okay, any that are obvious here that we've missed for instance what about I've got one that maintain the plugins dot txt file, or update the plugins dot txt file with latest plugin version numbers. Download latest plugins or download plugins defined in plugins dot txt. Another one is down is what would you say Oh, use and an incremental build an incremental build of a plugin in plugins dot txt. You're developing with the get client plugin for instance recently. So, mag or Kristen or dirage any others that you say hey, I would, I recommend this one. Does upgrade a plugin include reading the documentation to know what's changed. Not. Okay, that that's a very good one. So where to find the change log for an upgraded plugin. Good suggestion. Okay. And this is all for using plugins not for creating plugins right correct this is all about managing them and installing new releases of them. Yeah. I use with Docker. Creating a Docker image that contains plugins already. I've got another one. Use with helm, helm charts. And again it's creating a Docker image that contains plugins, a custom update center location that's an interesting one. Okay plugin version formats is is there's there are defaults. Latest, precise version number, and then incrementals version number. And Kristen do you know is there any way to use snapshots. I haven't found a way to do it. Because as far as I could tell snapshots aren't publicly downloadable they're entirely local to me to do that. It might be an open idea but I, it's not downloadable. So, it's not going to be, or at least the tools not really going to try to look at your local system. Right. Okay. And she can't physically slap me from that distance on what about reverting of updated plugin rolling it. Oh, very good. Yes, that is an excellent story. Reverting. Let's see. What's your preference rollback plugin update. Okay. Right now we sort of tell them abandoned hope all you enter here I think right. Right. This one this one is a really good one because my default mode is to not use this magic up this magic argument latest latest faults. And if I don't do that, it actually won't roll me back. So yeah that's an important one good so rollback a plugin update is a really good story. Okay. Does it get complicated what if you have a plugin that has a dependency, and one of the dependencies gets rolled back but you don't roll back the plugin that's called good okay so rollback of a plugin of a plugin that is required by other plugins. That's the way to say it. Yeah, so it's. And that that one could be interesting. Yeah, so rollback how about, how about we do to because that one rollback a single plugin update and rollback an update of a plugin dependency. No, is it. It's not really multiple those yeah I was going to say multiple but really it is. Yeah, interesting. Good, good question very good. Are all of these use cases assuming public plugins that are in the very good using private plugins. Very good and let's that's down in here. So he's got the topic already if I remember right which is custom update center privately maintained privately maintained plugins. Right. What about the issue of updating plugins on a highly secure system that does not have much internet access. Oh, okay that's a that's a fun one and I think the answer is you're out of luck, but let's let's put it here so this does require you to be able to point out an update center. Good to have it as a something just like a mention and then maybe we can come up with a solution or like for it later does that make it like I don't know if we need actually it's interesting work to be to have all of this filled in like for the first push or oh no no no. No no this is very large PR. Well, and it's, it's already a bit of a daunting PR, just as it is so so yeah no I'm not, I'm not thinking that we, my worry is I reviewed the PR was, wow there are many use cases that are not covered here but there's that doesn't stop us from getting the ones that covers included. It kind of looks like they've got the really big ones out there too. And we probably ought to prioritize just to be sure hey, or I guess we just take the ones we've got and know which ones are not covered. So air gap configurations is is a really good one is, and the answer is not supported. Right. Right. So, or air gap configurations require an update center reachable from the air gap from the from Jenkins. Right, which means they have to if they're going to air gap they also have to air gap their update center. Good. That's a very good story. Okay. So I think we had one already here. This single. Well, no where was it. This one. Okay, the thing I'm wrestling with is I put these three things in here and I'm this one is not mentioned anywhere so that one's actually could be useful at least is for me. This one I think is already covered elsewhere in the body of it. I think we've already got it. And this one I, I haven't seen it that I recall. All right. So there are other suggestions of use cases. Okay, good list. Yeah, well and and just it's a good thing for me to use as I go through that that poll request one more time so that we get it, get it covered and we can identify which things are missing so we do them later. Great. Any other topics we should go through today. And let's call an end of the session. Thanks very much, dear Raj. Thank you again. Thank you very much for your help. Thanks Meg. Thank you, Kristen. Have a great night and a great day today. Dear Raj to you. Thank you. Have a good week. Bye. Bye.