 Welcome everyone. This is the 9th of February. It's Jenkins documentation office hours. Topics that I have on the agenda action items LTS release. FOSTA summary documentation transition prep for Centos seven end of life. Interacting with candidate contributors from GSOC and pull requests of note. Now, since you joined us, there may be topics you'd like to add to the agenda. Are there any specific topics you wanted to bring? I'm a newcomer contributor. So I've taken an interest in the plug-in health scoring. So I would like some guidance or I mean something to point me in the right direction because I'm feeling pretty lost in the code base. Okay. All right. So, so that's a that's a good question. I'm going to given that that's not quite on the documentation topic. If you're okay with it, I'm going to get us through the other topics. And if we've got time, we'll get to get to that one. Would that be all right? Yeah, of course. Okay, great. All right. So, again, health score project. And how to become more involved. Good. Okay, good. Yeah, so I'm not, I'm not especially skilled in it, but we may be able to answer some of your questions. And answering questions sometimes is all that it takes for someone who's interested to then make further progress. So let's take that, but I propose we still take it at the end. Any other topics Bruno any topics that you want to need to add. Okay, good. All right. So action items, no open action items. Yay. Congratulations. We just released the long term support release 2.375.3. The change log and upgrade guide was out, but I realized there was a miss. So it looks like we missed a, at least one LTS candidate in the, in the backports, meaning it was included in the Jenkins issue tracker, or labeled in the Jenkins issue tracker, but then missed in the backport. And what that is is that means we, we missed in our review of the backport pull request. And the gap there is, as we review, we should have also caught it in our review of the change log. And what that really means is that I'm not doing a good job in the change log review of look at LTS candidate issues in Jenkins Jira to confirm they are all included or or rejected, or marked as rejected. And I hadn't been doing that so it's this is a process improvement for our review process. The LTS baseline has been selected 2.387.1 and look promising. So that'll happen March, March 8, 2023 is the release date. So it's still the same process as you explained the other day, looking at the number of problems a release has to know if it's a good release candidate or not. Right. So the release team there so the release, the release officer propose that version based on based on ratings results and general experience and then the community thread discussed it and agreed, and it was selected. So the ratings are only people complaining or not complaining sending a report when something's going wrong with the weekly release. Actually, it's it's a little more than that. So if we look at the, if we look at the page we go to the and I'll put a link on to this page. We go to the change log page for weekly releases. The rating system that I'm referencing is is this system of clouds and sunshine. And that those clouds and sunshine. We get we only get a cloud we only get sunshine if someone reports a positive item. So it's not just it's not just negative comments and in this case, we see there was one I had to roll back here one here, even one here but 50 plus in the last several. So we're, hey, no problem. Thank you. Yeah. Next topic, anything else on the LTS release. When with me say on time. Okay. Fossum summary. This was my first time. No problem. Fossum summary. So Bruno, maybe you can give a brief summary of things that went on a Fossum and Howard. Brief will be difficult. It's very intense. It's two days in Brussels where all the people from around the world imply involved in open source, come discuss present share show. Wow, whatever. We had a booth we were five, six, seven depending on the hours around the booth from the Jenkins project and trying to answer. No, succeeding in answering all the question people had. But most of the time people were just coming to say hello, we do love Jenkins and we use it and we. Yeah, we like it. And the things that came and came and came again was what the near future of Jenkins because people love Jenkins they use it extensively. But they know the UI UX is not up to the standards. So as a light, you know, if something is cooking or if we just keep the old HTML, we're all used to. And fortunately we had, I don't know if it's demo proof of concept or just a mock from Jan and team, I guess, which was running. And that was which we shown people because lots of people were also loving blue ocean, you know, and they wanted to know what's going to happen with blue ocean. And lots of them were kind of sad when we're telling them no new features only security updates and fixes but that's all you should think of changing or just letting letting that alone. And they were pretty sad about that but when we shown them the proposed revamp of the UI, they were relieved. In fact, so they knew that Jenkins is still going strong. We've spent some time cleaning up the UI UX and now it's almost ready for the new generation of UI and UX and that's important. Yeah, that's the part that people are not super happy with you know just a UI UX, which is getting old, but it's getting better and better every month I should say even now not with a prototype but just what we can see from now. Since last year it has changed dramatically already, and it will get better and better. We didn't get any angry people about Jenkins, but people loved Jenkins not happy your sticker, you know the one with the flames don't you get when you go to 500 a day or something in Jenkins, just love it. And yeah, most of the time people were just saying hello we love Jenkins your project rocks your t-shirts rock your stickers are over the top. You're fantastic. Yeah, yes we are. Of course, the project is 18 years old, or something like that, and it's still rocking. What could you say a lot of people wanted to interact with us to propose some partnership between different communities. They wanted to testify about their use of Jenkins. We had the CERN CERN, some people from the turn so the place where the worldwide web got invented, saying that they were using Jenkins to collect and process their IOT data. For example, some people from big automotive companies also were testifying about their use of Jenkins and so on and so on. Amazing. I knew already that there were lots of different industries using Jenkins, but real people in front of me saying in front of my face that was a whole another experience that was super cool. And not linked to Jenkins, but what I attended there was people interacting with each other trying to help each other to share some knowledge. This was very refreshing to see that for real instead of the GitHub or mailing list. That was quite an experience. Sorry, I wasn't brief, but I'm still enthusiastic about that. Thanks very much Bruno. Thank you. Next topic then documentation transition to Java 11. So this conversation started a month or two ago, when we realized that when Debian 12 releases in April or May of 2023. It will not include Java 11. It won't be available from the standard Debian 12 package manager at all. You can only get Java 17 at that point for Debian 12 from the Debian project. And because of that, we don't want to have one document that says this is how you install on Debian 12, and we fully support Java 17 so the decision is that with that release or about the time of that release will transition the installation documentation from Java 11 to Java 17. And as Debian has progressed further, we've further decided we're going to do that for both Windows and Linux, because Java 17 is supported on Linux and Windows by the Jenkins project, no problem it keeps things consistent and encourages people to move to Java 17 sooner, so that they, they can get more experience and understand and get the benefits of Java 17. Yes, we even have seen some performance increase when using Java 17 if I'm not mistaken. I think I read something for Bezel saying that. It's not totally linked to that, but we told the other day about the, there is no reference to Tamarin for time being in documentation. It's Tamarin, you know. Oh, right. And I don't know if it's an open action item or whatever, but I don't know if it's still relevant. So do we plan on writing something somewhere in the documentation related to our use of Tamarin? Of course we're using Tamarin for our containers, but I don't know if that makes sense to tell about Tamarin because we'll rewrite all the documentation for open JDK 17. Well, so I think there are two different things there and I believe I thought I had actually created a bug report, but no, apparently not. So we, I know we had a mention of it. Let's see if I can find the mention maybe there is an action that I just failed to complete. Should we more clearly describe our use of Tamarin and didn't we put an okay Tamarin. Maybe it was my job in the platform. Maybe I failed. I don't know. Well, but let's, this is supposed to be a working session. Let's just create the issue. Let's, let's go ahead because there is no reason why we should not acknowledge that okay Tamarin here. So should we add that we had the open question, but it looks like we didn't ever address the question with a specific action. So let's make an action. Let's do this wrong meeting. I was wrong. It was the documentation office upwards. Well, but, but the, oh, oh, no, no, look, I'm looking in the wrong. I'm looking in the wrong repository. Just a moment. Let's find the correct repository. We don't want core we want Jenkins.io. If we look for Tamarin. I would hope we'll find an issue. Oh, no, okay. Good. So let's create an issue. And this is a documentation item which should be note the describe Tamarin preference of the Jenkins project. Right. So the idea here is the Jenkins container images. Controllers and agents include Eclipse Tamarin as their JDK Jenkins infrastructure uses Eclipse Tamarin, or builds and tests, right. And the controller builds are done with Tamarin. We should document we should describe our relationship with Tamarin and our use of it on the maybe on the Java requirements page. Or elsewhere. Yeah, thank you. Does that seem reasonable. It is to me. Let's create a link to the Java requirements page. So, got it. All right, so now we've got an issue to track. And let's drop that into the notes. Hey, no issues submitted to docs repository. Thanks. Bruno anything else. No, thank you. Okay, next topic. This is a new topic for the Cento seven end of life. So this one has a broader story to it. Part of it is Mark Waite has a strong bias against Cento seven right that's that's really the reality. And that's strong biases because it has an ancient command line get. Yeah, of course. I've been using, you know, the years before I was using extensively sent to a seven because I was forced to, and it was a mess I had to recompile curl, get lots of things to keep seeing almost secure. Exactly. Well, and, and it's, it's, it was deprecated, or it's, it's, and it entered maintenance phase. Yeah, three years ago, two and a half years ago at least. And it's actually end of life from the Centos project in June of 2024. I think, and it's already not supported by our RPM installer, since the change to system D. Yeah. And the container image that provides Cento seven and that we use as our basis was deprecated late last year. So, so given that, I think it's time it's it's okay for us to start the process of preparing to end this the life of Cento seven we don't have to feel duty bound to keep supporting it all the way until June of 2024. And what's the name of the replacement you be you be eight you be nine and Tom, or well so there are there are several different replacements right it's a good good point replacements include. So, let's talk about if you're talking about a desktop or server operating system, then you can use. Let's see you could use Alma let's do them alphabetically Alma Linux, eight or nine. You could use rocky Linux. You could use eight or nine. You could use red hat enterprise Linux, eight or nine. You could use Oracle Linux, eight or nine. Any one of those is a viable replacement for Cento seven. If we're talking about containers, then the container choices there's ubi eight ubi nine and Alma and Rocky. There's containers as well. So, so there are lots of lots of options to, to replace them now none of them use ancient command line get. And none of them use the ancient SSH and so if you were somehow critically dependent on those ancient versions they won't do that because they've all long ago upgraded from those ancient versions is something more modern. So, I haven't looked at documentation, my bad. Do we tell anything about CentOS in the current state of the document. Yes, and that's the problem here, right is we've got. If we look at the documentation. And that's I think the problem we want to solve. We've got documentation here on Linux, and we've embedded a video that shows how to install Jenkins on Cento seven. I want to take that video out. We can replace it with one that does eight or nine because I think Darren's created that video as well but that video should be removed right should be replaced. I'm confident there are other things like that scattered throughout the documentation where we need to seek and replace any mentions of CentOS seven with CentOS eight or better yet CentOS nine. So should not say red hat nine or Rocky nine or Alma nine or etc. Yeah, should we make an epic in zero some thought like you did with a JDK 11. That's what I'm wondering if we ought to do some way of deciding that hey we've got work to do. Yeah. So, maybe what we do is we put here an action item that says create a tracking or create one or more tracking issues to track the work to replace to remove CentOS seven from the docs. Should we make an exhaustive list of the potential replacements or just stay vague or say that we prefer that people use I don't know for example Alma or who should decide of that. Yeah, so and that that level hasn't been decided we've never bothered in the past to recommend one operating system over another one vendor over another here we've got the Linux requirements page talks about pay supported or not. And, and so in this case at the moment, CentOS seven by this definition is level one supported because, or maybe I don't know maybe we don't run automated package manager installation tests. So that's another thing for us to check is. So, check that automated packaging tests. Or maybe what we should say is stop running. Automated packaging automated packaging tests of CentOS seven. If they are running now. Remove them, because then the announce deprecation of the CentOS seven containers. And so they're there are a number of steps here that we've got to do. Take those and those I think you've got a good point Bruno let's capture them into a into a bigger a bigger something. Good. All right. Any objections to that idea Bruno. No, not at all. That's perfect. Okay, good. We are nearly running out of time I propose we skip to the end and let's see if we can answer some of say on tons questions about plug in health score and skip the other topics. Are you okay with that Bruno. I am sorry I talked too much. That's great. Okay, so Anton what's what sorts of questions do you have and let's see if we can help. Yeah, so hi, I started contributing by, and by putting small peers in the plugin site so two of them were immersed, even though they were small changes I mean it was quite exciting. And there are two still to be reviewed. So I thought about, I should start contributing to a major project so dear it's over told me to take a look in that project plug in health scoring. Okay, I'm going through the commits one by one so which were done in the previous these are, and I'm understanding the code a bit but I'm not able to understand where should I start from, where should I start contributing. So, can you help me. Sure. Well, so I'm going to I'm going to offer some ideas of first first let's look at what does plug in health score tell us today. Because if you haven't seen it yet. So plug in health dot Jenkins dot IO shows us the current state of the plug in health system so see the current site at this location right, and, and then if I look at this talks about which probes are available. If we go to the results page talks about okay, which, how many plugins are having a problem or have hit that particular probe. So we have 294 plugins that are using this JEP 229 and almost 1800 have a correct setting for SCM. So that's that's give some indication now. The scores thing here shows here are some of the ways scores are involved and then there's the secret thing you can look this way to see what what the scores are of a specific plug in. Let's capture that and I'm going to put the notes here scores for specific plugins at this look that kind of location scoring scoring system at this location. I'm not sure it's santa that any of that has helped you as much as, as you might have wanted but that gives you some overview of what you're looking at first. And now back to your question, it was, are you are you wanting to know how would you approach adding a new probe like one of these simple probe ideas, or are you thinking how how would you compile the code how do you interact with it. I'm thinking I mean how should I approach a problem because I'm new to Java and I really don't know what I should contribute right now and there are not many issues I can work on in the get up page so I'm really confused where should I start. Okay, yeah so well so let's, let's talk about let's look at some of the maybe what we could do then is help by describing some of the things you might consider as possible probes. For example, these are existing probes. But we have, we have plenty of things that we might say, Oh, what are some of what are other things we might ask about what's the quality of a particular plug in how good or bad is it. And that's how you would choose to write a probe so the idea here was, let's see let's look at this. Some of the things does the probe have a can does the Jenkins plug in have a contributing guide. That's actually not a bad one to choose to say what if you wanted to write a probe that did that. So let's let's take an example so choosing how to so I think your question is how to explore the plug in health score project and its source code. Is that a fair way to say it. Yeah, that's. Okay, so first, first the key things are answer. What's a, what's a, what's a plug in, and what components. Why maybe this one why, why do we care about the score of a plug in, or what's plug in health score. And why do we care about it so a plug in. So I think I have the answers to some of the questions so correct me if I'm wrong. So plugins are like we use them in the Jenkins to make our work easier and they are available in the plug in site. And the plug in plug in health score is evaluated using pros which are many factors, like if a plug if a plug in has a SCM or it is being updated early, or it has a different award. Plug in health score is evaluated between zero and one. And for the third question, why do we care about the score of a plug in it so that the people who are using Jenkins can take an informed decision about whether we should continue or we should implement that plug in, or maybe go with some. Very good. You got it exactly right. Excellent. Okay, so so then let's take the next step. What which scores or which probes might be useful to add. Right, so which things might contribute towards a the score of a plug to towards are deciding if a plug in as well maintained or not. And this is where we could we could look first for a little bit of cheating ideas Bruno and I created a tutorial on Jenkins developers on modernizing a plug in, and a plug in that hasn't been modernized is probably a good candidate to decide if it's if it should lose lose points on its score because it's not been modernized. And so what this gives some hints. So, look at improve a plugin for ideas and one of the ideas that's that's in in the in health scoring idea here as a contributing guide is actually also one of the things here on this. So, okay, that's probably a reasonable choice. Then the question is how do we decide if a plug in has a contributing guide. I'm going to read this tutorial and it says a contributing guide has the file name contributing md. All right, so all the probe has to do is ask GitHub, does this plug in have a file in its repository name contributing md and if not, the score should be zero or that not the score that the probe says no contributing guide. And it says oh yes has a contributing guide. So does, does that give you does that give you sort of an end to end, at least starting picture. Yeah, it gives me a picture so it's going to be kind of a Boolean value. It's true. There is a guide. Right. That one would just be a Boolean right because existence or nonexistence is purely a Boolean right. You know, another probe which is already using such a thing like Boolean yes and no, that could be a good starting point for Cientan. Very good. Yes. Actually, excellent point. The deprecation plug in is a Boolean. It says either it's deprecated or it's not. So that's one another Boolean is the adoption plug adopt where is the adopt one up for adoption is another Boolean. So there are some Boolean probes already that you could use as a reference to look and see. Hey, is this. How could I use the code from an existing Boolean and create a new probe. There's also the Jenkins file probe which is testing the presence of file in GitHub repo so you could combine the two of them and have something. Oh, no, I'll just start from this one because Boolean plus five validations or why not. Right, exactly Bruno's right this is this is okay we just we went through the thought process found two that were reasonable and now he's found the best. This is the best one because it does exactly the same check it looks instead of for a contributing md. It's looking for a file named Jenkins file in the GitHub repository. So, so the probe would be do what Jenkins file probe does. But instead of checking for a file named Jenkins file check for a file named contributing md. Right. I think so anyway I don't I don't see any, I don't see any shame in doing that because, hey, this has been written. Great, let's use it. If it's got mistakes, the review of your proposed new probe will help highlight any mistakes that might have been in that old one as well. So, yeah, and then I put the link into the meeting chat, you should have a chat button somewhere if you click on it you will have the three links. We talked about during this meeting, just before the meeting and then the link disappeared forever, or you will find them in the document that mark was written reading, writing it. Right. Cool. All right. Say Anton is that is that enough or is there additional that you'd like to ask before we conclude for today. Oh, no, that seems to be enough for now. Great. All right. Thank you so much for it. No, thank you for contributing to Jenkins. Yeah, and thank you for joining documentation office hours well done. And we're here every week so don't be shy if you've got questions in the future you're welcome to drop in. All right. I've heard all the topics I had for today. Any other topics. Not from my side, thank you. All right, thanks everybody the recording will be available in about, well I hope within 24 hours.