 Welcome, it's documentation office hours is the 8th of June 2023 topics on the agenda for today include 2.401.2 20401.1. A poll request for from a new contributor end of life notifications container end of life and a couple of topics from our last session. Anything else you want to add Bruno. No, thank you Mark. Okay, so Christian is acting as release lead for 2.401.2. And we'll need to create the changelog. Kevin Martins is planning to be back next Monday. So we he may be able available to do the changelog and upgrade guide. Hoping and if not, we'll take care of it in the docs team. Next topic is related to that but it's sort of an embarrassment in the live stream. There are at least at least two items. Yeah, two items that need to be deleted from the 2.401.1 changelog, because they were already delivered in earlier releases. Earlier LTS releases. But the two of you really handled that beautifully during the live. Well, yeah, okay, me being embarrassed and saying whatever we made a mistake. Yep. And that's okay. So we've got it. We've also got a new poll request from Jeffrey Chan. Yes, I've already done my review, but it's very low level review. You know, it's just a few things changing comas or world, something like that, but we need somebody who has a better picture from far away for the other way to change things because of course some things have changed since the week he was created and some things are already in other parts of the documentation. So yes, please make whenever you have time. Your review is welcome. Exactly. So where the real question is where should we put the things that are there if if they if they justify keeping them and if not, what do we do with exactly. Yes, but I can see that Jeffrey is still motivated. You know, he's doing merge from master into his branch twice a day. So he won't have to be covered. That's cool. Thank you Jeffrey. Yes, and that's a good sign. Good. All right. End of life notifications in Jenkins core have are now live. They became available in 2.407 and a fix is included in 2.409 for Fedora 38 and next LTS baseline in about 10 weeks will include it as well. I don't know if go ahead Bruno. No, no, it was just a stupid joke but 10 weeks from now mean that will be in August 10 weeks from now. It goes way too fast. My brain is still in April. Wow, I wholehearted agreement. Absolutely. So so August is the plan and we look forward to it. Now we've got an additional idea that I don't know when it will happen because it's lower priority for me than other things. It is that our container controllers should be that's this color this. We have a further idea which is agent control or container agents. End of life needs even more work before it's possible. So what we've seen is well but Bruno you had done you had done some work on the container agents builds recently, and it's possible for users to be referencing a very old. Agent container agent image and they they get no warning their administrators get no warning there's no hint that you've chosen a dangerous outdated controller container image or control agent image. And so the idea here is if we can find a way to warn people that they're running old agents, it'd be good. I guess one thing is node version node versions node monitor plug in. And already provides something like this. Oh really. Okay. A report on outdated versions of Jenkins Remoting and and and JDK. The platform labeler provides automatic labels of agents. So, so we're pretty comfortable that it's possible. Yes, but the question is with or without touching the images of the agents. And I think that's a piece where well platform labeler hints that it should be feasible without touching the agent. And the container image since platform labeler looks at the agent. For instance, it looks at its operating system and says this operating system is such and such a version. So we could do something like that and say we could conceivably extend the end of life notifications here and say sweep through all the all the play all the agents and if any of the agents have a. Maybe that's an enhancement for the platform labelers if your agents have end of life have reached end of life we somehow put up a monitor there. That would be interesting but the thing is, will everybody have a version of platform labeler in their Jenkins instant. No, they won't so that's that's a good point whereas Jenkins core does, does have that they would always have Jenkins core. Yeah, good point. That's interesting nonetheless. If platform labeler could reuse what the kind of framework you put for in the Jenkins core. That would be interesting. And it already does. I did not understand I had to look at the platform labeler code but I did not fully understand how the magic was happening. And it doesn't really for sure you know the other day I tried platform labeler with Jenkins running on my Android phone, and it managed to find it was Android and it was working so why not I guess this is a very good foundation for the rest of the work. Yeah, oh it does it reads a file from the, the agent file system. I don't know about the magic I just want to experience magic. Yeah, and, and that's all that that's all that the end of life notification does right is it reads an ax on a file in the file system so not a not a complicated thing if the agent operating system is helping us with that now in some cases, Arch Linux the agent operating system will tell us what what operating system it is. The case of things like Alma Linux eight the operating system is not end of life, but we can tell that it exists as an operating system so it's those kinds of subtleties that have to be handled. All right, anything else on on the agent on the end of life concepts. Not for the time being thank you but I guess I'll have lots of question when the meeting ends, as always. Okay. So we had a leftover question should we document tested operating systems. I think it's a good idea. Maybe the simplest approach is let's create a Let's just do it now. Let's create a ticket that that describes it because there's no reason to leave it in our notes let's just put it right here and create an issue that says, let's do. This is a website enhancement. No, this is documentation. Include tested operating systems tested JDK's and operating systems in change in change log or upgrade guide. When we release a new version, we test many operating systems and Java versions. It would help the user might help some users. If we documented those configurations. At each release packaging repository reforms most operating systems specific tests. There we go. Issue submitted. Thank you. Yeah, maybe that's a stupid question or maybe that's not the right meeting to ask this question, but if there is somewhere of the systems we are testing on and by system or operating system. What do you mean real machines VMs not darker. I suppose. Actually we test in in multiple ways. So, and, and you'd have to read the repositories to see which tests run where. Okay. Because it's a good question. Let's do a quick look just to see. So for example, in the Jenkins packaging repository, I think it's Jenkins CI slash packaging. Here if we look at the CI job. And I'm not sure if this one has a nice pipeline overview. No, it's, we would have to look inside the content of it but what you what you'll see when it runs its test is when you expand the list of things being tested. And is it is it this one 19 minutes worth of testing. Here we go. If you scroll to the bottom of this and you can see all sorts of things that are tested here where they're listed. Hey, we're testing this and this and this and this we're testing. We look at nine and we're testing, etc. So all sorts of interesting and useful data is hiding in this about. If we look at it if I look at it from the peer console view what we'll see is we look for. Let's look for Rocky. Here you go. This is Debian 1011 went to 2022 Alma 89 Amazon Linux 23 Cento stream 89 Fedora 37 Oracle Linux 89 Rocky Linux 89 open Susie Leap 15 all tested. And so those are candidates to be described. My idea behind that was, would it be easy or not to maintain by a real human or could we automate. No, we would, we would, we would definitely want that automated yet. Absolutely. We would, we would without a doubt want that automated. Of course, because I think that would be a pain in the neck to try to maintain that by hand, because it's always changing. It certainly is that's correct. Yeah, very good point. Yeah, the matrix we say matrix because maybe we are testing on several different CPU architectures for the same line of distro, for example, for the same operating system. So maybe we should have a matrix some somewhere that describe and we may even discover things that we don't know yet. What is tested on what system where it's a VM, it's a real machine or interesting nonetheless. Well, so as another example of places where we do testing. We've got this one right here. Let's go to this thing because I never remember where it is the release checklist. Oh, I know where it is it's right here. We'll go ahead it this way will go this and acceptance test and if we look at Debbie and latest for example. So here is a set of tests that run on various operating systems to test packages for LTS and for for weekly. Again, that's another part of the testing that happens acceptance tests. Yeah, so maybe the first task would be to find all the source of information right and then say, hey, these are the things and then of course we've got the weekly or the CI tests of the of Jenkins core and it tests certain operating system configurations we've also and the acceptance tests when interestingly enough runs on if I remember right if we check this one we should see that it runs on system 390. Yeah, so it runs on containers on AMD and on system 390. So yes, yep. So it's captured and I think we can use that as a good starting point if someone wanted to work on it. See it was CI more core. There we go. And let's just take this one and the last build the last successful build because that's the easy way to see it. And then on this, if we look at the overview that gives us a very quick. There we go. All right. Any other topics other than my still needing to submit on the main newsletter anything else. No mark. Thanks. All right. Thanks Bruno recording will be available in roughly 24 hours.