 This is the Jenkins Docs Office Hours for the 2nd of November 2020. Let's take a look at the agenda and onward we go. So topics that I've got, progress on pull requests, Docker changes to use the official Docker image, Hacktoberfest results, what's next after Hacktoberfest? Any other topics that any of you would like to put on the agenda? Let's see. Oh, and we had one. I had notes on one we were going to consider doing a demonstration of tables to divs. Where is that? Oh, exactly. Oh, here it is. This runs to date. So if you're okay with that, let's put that here. Demonstration of Jenkins 2.264. Tables to divs. UI improvements. Nothing else. Let's go ahead and start to start the topics. So progress on the Jenkins.io pull requests. Please to note that we've got 56 issues that have been closed in the last month. So during Hacktoberfest, 72 pull requests that were merged during Hacktoberfest. And three new issues that were reported from in part from people helping with that. So previously at 36 or 37. So we've kept parity with our number of open pull requests. And our number of open issues has dropped by over 40. We were at least at 156 at the start of the month and we're now down to 115. Wow. So go ahead, Meg. That was it just wow. Did I say I said it was. Six issues in the last month. Yes, 56 issues close 72 pull requests merged. So excellent, excellent result. We do need a blog post. That was an item here on Hacktoberfest results. But in order to get that we need the data. And pull, I get done a bunch of work on the data to assure that it's accurate. Just need some time to go collect it and highlight it. Any questions there or concerns, any things? Hey, we, we did this week should have done that instead. Mark, there is some kind of agent, for example, to retrospective just to map it and the learning things during the event to use the next one. Like the, for example, the guy with help us with another way to use the host file. And how to handle it to issues we are something like that to make some reports to the next members in next events to all the blog, the blog posted will embrace everything. I see that's a good suggestion right so. Yeah, I think, I think I see what you're suggesting that we should offer special thanks to in this case it was that it's Tobias for the improvement in the redirects is redirects definition and thanks new contributors or the redirects Jonathan for identifying the need for the redirects. What the redirects are because most people will have any idea what you're talking about. Yeah, actually very good. That is a good one that there, there are, there are many different facets of this particular project that each one of them highlights an attribute of working in a community that we work better and by helping together. So at the end of this, did we come out with our most of the good first projects completed. Oh, somebody new comes in notice still plenty of stuff there somebody new pops up and wants. That's actually it's another good thing that we should highlight, because if we look at the number of good first issues that are still open. No one assigned to them. I think we'll see 20 or 30 still. So we have 19 open of those 19 good first issues. It looks like roughly nine or 10 of them have someone assigned. So we've got at least 10 good first issues still open. Okay. Well, in this case, we can decide, for example, just close every 10 issues with just one PR, or give or let them to their next members. What we need to do. So I'm not sure I'm understanding your question, could you ask it again Jonathan. Yeah, it's because we open all these issues for new members. So the event is ended. So maybe we need can close all then with just one PR or just leave for the next next members. Oh, that's a good question. Okay, should we should we do a single solve open redirect for resolve open redirect issues a number of them won't be resolved trivially but redirect the open redirect issues. If we chose to say hey we're going to look at these and each one that says redirect so this one this one this one. We could choose to do a single PR that would resolve all those redirect issues in one one exercise. Yeah, I like that. I think that actually would would have a positive of resolving the easy ones. We did. We did good first issue. And now these are relatively trivial things that we can do and then it still leaves the ones that really have a migration in them. It's visible to users is visible to people. Good. It's a option because the main objective was the event. So, maybe a good point. Very good. The Toby X propose it's already news or not. It's under appreciation of Jenkins. It's already been merged and in use as far as I know, right. I'll have to double check it's definitely been merged. Let's check to see if it's been deployed to production. Let's see if it's been deployed to production. That's Jenkins GitHub. And we'll just change to this one. Okay Jenkins info and pull requests. So his pull request was right here. That's not the right. Yes, so it was merged two days ago. Now let's look at the other close ones because there should be one call request which says go to production. Five days ago, 13 hours ago. So yes, it is in production. So, so the redirects from his close redirects are merged and production. Do you know how to use the new rules? I didn't see. Yeah, let's let's take all he did what he was able to do was delete the simple if I want to add a new redirect. What I need to do. You would do the same as we did before but instead of using two lines to do it, you use one line. You can find that PR again. PR closed. We've got to do author. There is a blank space. Yeah. There we go. Okay, so this one. Reduce wiki exporter special case to one rule what he did was he changed all of these individual rewrite conditions. They're in there as special cases for the Jenkins wiki exporter into a single, a single rewrite condition at the top of the file with the rewrite rule. Okay, so if I need to add a new page, you just do this rewrite rule thing like we always did before. Yeah. Yeah, so, so it's it's much easier as an example here's one that's open for me. I've got this one open to redirect the page about ping threads to Jenkins that I know and this is all that it takes one line. And you'll recognize that's exactly the line that we've always used. Now, in addition, during the Hacktoberfest period, I'm actually kind of proud of this one. Gavin Morgan and I created an automated test script that checks that vhost.conf file for correct contents for a number of mistakes that we've been making in the past. So we now have basically a set of automated tests, the check that our file is consistent. That needs to go into your blog to. Oh, yeah, that's a good point. Right. Let's put that right automated checks. It also illustrates the principle that we talked about but don't live by when you find problems fix the tests. Right. That's good. So, I'm going to watch your subtle soapbox. Yeah, just just what people want to hear is me, me beating on the beating on the pulpit of write more tests. Okay, good. But it's it's what but it's I mean it's more useful when you just say you should write more tests to say, here's a place where we wrote more tests as everybody should. Right. Yes, very good. Okay. That's a really good story to tell people. Thank you. Anything else you think we should highlight on October fest. So, Jonathan and Vlad and Meg are you willing to be co authors on this. I'm happy to draft it. And we'll just make it a the four of us as co authors. I'm happy to edit it but I'm contributing nothing here but whatever edits edits are our high contribution. Sure. My keyboard has decided to do something really odd. What was it doing. There we go. Let's try that again. Okay. Okay. Anything else on progress on pull requests. So, Jonathan you I think it asked, where is it to retrospective are there things that we should improve. Do we know how many people actually got t shirts or a tree. And I don't know how we would know that we we we can buy our own data to take how many different contributions there were and may even be able to deduce how many distinct authors there were, but which which reward they selected digital ocean doesn't disclose. There is some statistics. That's about who organizations help mark with contributions. For example, James or 1010% 50% of contributions get from James or not. I've not seen anything like that. So, so I'm not, I'm not aware of anything that digital ocean shares, but would be nice. Let me put it this way better tracking would be nice. Something like our access site. This is good for people. It's funny. It's like a game. Exactly. Right. Yes. Maybe Jenks create a new Florida stone world. Yeah, why not. We planted this many trees. Thanks to digital oceans. Okay. All right, next topic then. Dr changes to use the official image flat you want to share with us a little bit how that progress is gone. Yes, well, first of all, thank you very much Mark for your contribution because I noticed that you're in the last week, for example, you made several poor requests very important for requests. But overall, what I guess is achieved on positive side is that we're using right now. This image, which is derived from official Docker image. So we can trace the versions that downloads Docker images, which are mentioned our Jenkins dot IO documentation on download side. We used this contents of Docker file, which allows basically everybody to use it, and actually, well, also contribute to different, different images. Well, I wanted also to mention that right now, we achieved this kind of using all official Jenkins Docker image, both on installation part or documentation, and in the tutorial part or documentation. And tutorial part right now is kind of also are expanding. There are four chapters of tutorial part. Well, I checked, for instance, last Friday, and during the weekend on tutorial part on our documentation, not only simple Java, but something else, and it works. But today, we modified a little bit. Well, I noticed that we made some modifications. And I can test that I'm pretty sure the tutorial part will work. But in installation part we removed, well, some of the volume mapping parameters from installing, for instance, the home. I mentioned this, because my intention for today, at least, was to sync tutorial part and installation part. But right now, they are different. I figure a little bit further lower on your screen. Yes, you can see that it is installed part. Before we're using my Jenkins blue ocean dot one one, we removed mapping for the home directory, which is present in tutorial part. And the presence in tutorial part explained by the necessity of using home in some of tutorials, because in some tutorials we're not using GitHub URL, we're using local directory image. We mentioned home in installation part co mapping, but it was removed over this weekend. So, well, And that was for me at least that was intentional. So, so I didn't, I thought we shouldn't mention it. Are you thinking we shouldn't mention use the home home mapping, even for install see for me I thought this is this. No, let's go get all the way down. This where is it the one that maps. Oh, this is installing sorry installing we need tutorial. tutorials. So this is that's use the Node.js example it's a good choice. And so here is on Linux. Okay, this way. Yeah, so the one you're referring to is this slide right here right right. Yes, exactly. Well, it is needed for tutorials. Because this is how some of the rules are written right now. And, well, there is kind of plus and minuses for using this, I guess, well, we can rewrite of course tutorials but, well, one of the minuses, I can see that we're exposed. to using our, for instance, our home directory of client machine, but I'm not sure is it really minus or not it is kind of security concerns. My question, though, is, well, maybe people have different opinions on that. How do we make tutorials section, at least this is why my intention synchronized with installation part of the door related to Docker, because right now, since you mentioned this line is missing from installation part. And it forces us in the current implementation to use almost identical files in our documentation. So we're not really compliant to dry, don't repeat yourself principle, which is kind of best practice for documentation. So, we can still use this almost identical files, or we can put this home mapping again in installation part, but I'm not sure if there are maybe some objections from different team members. Maybe it will be, well, some security concerns they may have or not. Yeah, it's, I guess, up to our team members to decide. But this is what I noticed, basically all of this today while exploring this. Go ahead, excuse me. Yeah, but overall, I think it is a pretty good achievement that we are personally using official Docker image we introduce the content of very simple Docker file, which allows contributors new contributors to utilize this and like build their own images. The only thing which are maybe further improvement. We're not showing how to contribute to official Docker images and releases but it is absolutely different topic separate topic, and I'm not really sure if we need to do this. If it is worth doing and so on. So, this is what maybe like huge exploring how to actually we like showing the example of how to create Docker images, how to name it, but where to put how to put which registry to use. There is some communication going on going on right now with Docker open source community. Also, maybe there will be some feedback from their communication as well. But overall I think it is like positive thing. I'm not sure what everybody thinks about this but this is my question. I have a dumb question here. Um, so this gets me if I'm a first time Jenkins user and I'm just fooling around on my own. What if then I want to go in on Monday after my successful weekend and I want to set this up for my company. I don't want this to be under my home directory probably right it needs to be under. Is there a separate place where we discuss, sort of first time set up for production per company. Or do we just, you know, do we give it to him to play and then figure they'll figure it out from there is that valid. I think the fundamental model was that that installing is there ready for production and tutorial is disposable. And so I thought that that was why we would justify having this difference. But I still think that the principle that Vlad's alluding to the don't repeat yourself principle is a good one and we ought to see if we could find a way to have a single source file. And that conditionally has this volume magic in it, when it's in tutorial context, and doesn't have that that volume magic when it's in the install context. Right. I think we've done it before with ASCII with with ASCII doc, I believe I think there's a way to do that with with variable definitions that we put at the top of files to say hey, when we import this file in this location to find the variable to be the empty string. When we do import it in this location to find it to be this non empty string. We had to look into this like more details and figure out how to do this. But my straightforward attempt to synchronize I even created like branch trying to make it more maintainable the entire documentation content and so eliminate this repeating files. After that I like found out well they're not identical. Exactly. Because like you're in the Before this weekend they were almost identical like some minor changes not in the code button just the word which, of course, is not very well there is a point we need to consider about the dry. It's a common problem say it's a good really happens with, for example, if we point to another part of our documentations. We have no control with the origins change. So, for example, you are writing a new tutorial right now about how to use Jenkins with Docker or whatever, and point for another content, another talk. So maybe one month that that origin top cut chains. And that changes invalidate your right to talk. I make me clear. So it's complicated. Maybe we use out for descriptions in each tutorial to keep them complete. So, and as a cutable to begin to add. And I think, I think that's the problem you're describing is very real that there may be times when one part of the document describes something that's no longer accurate. I think in the case that lands describing here. I'm going to, I'm going to bring up a terminal window and, and look at this with my favorite text editor just a minute because I thought that they were pretty close to each other already. So, Vlad, I think these are the two files you were alluding to underscore Docker and underscore Docker for tutorials. And if we do our friendly local ediff, it will compare the two. Okay, so here's a change a difference in the comment for the purpose of the file. And then differences in the headings. The home, the mount of home. The explanation of the mount of home the mount of home difference in heading levels difference in heading levels, and that's it good okay. So so your, your desire to not repeat ourselves echoed with my desire that I wanted the same thing. And right now they are quite close to each other as copies. So differences in headed level heading levels. Can it be adjusted by a setting in the entry block of the file where we import this. So that that difference we can get rid of I think. So the only difference we really have right now between those two files is that exactly the thing that you observe this mount of the home directory for tutorials. I would be glad to look into this one. And the reason why I thought it is a little bit well, kind of annoying and it would be easier to maintain in case of a single file, because of the comments at the beginning of both files. I think it is for both files. There is coming that if you change something one file, just make sure that it is mirrored in the other file which is kind of for any editor use. Yeah, kind of extra efforts. Yeah, so whole heart agreement so if you're willing to investigate the, how you use variables inside a doc files. That would be a that would be a marvelous next step because then we could get rid of. We could get this throw one of the files away and just use the single file with this, this conditionally defined variable at the top of some files and not at the top of others. I like that. There are a couple other places like setup wizard, there is a wizard for which is used for installation and setup wizard for tutorial, which, well, the content, almost exactly the same but we're using for historical reasons I guess couple files which we can just improve. Excellent. Yeah, it's worth adding a pros note after that also though to say that note if you were doing this for production you do not want this under your personal home. We certainly we certainly could there is a there this this is not it's not so much dangerous from a security perspective, because they still have to authenticate to get into the Jenkins range. The authentication is that's they created the account it is still every bit as secure. The reason that this is actually for me anyway the reason this is not a good idea in production is it will only work on agents that have access to that file system. So, so the tutorial has you use a git repository that is locally mounted right locally mounted git repository is just fine so long as you're always running on the controller. As soon as you use an agent that's on a different computer the file system is not visible and you're stuck. Right. My concern is that somebody sets this up and the whole company is running wrong smoothly and they leave the company and close their accounts and all of a sudden everything is broken. Yeah, might not be trivial for them to figure that one out either. Here in our companies have policies so installing the home it's not the option. It depends of the company rules. So if some company allow their people use the home directory, the problem some companies not about the true. I'm thinking of like smallish companies just getting started on this with somebody who's not a real sophisticate setting it up. And I don't know how. Yeah, maybe I just a topic there, alerting their magazine, for example, in productions, please don't use slash home director. Yeah, right, right. It certainly could be added to this description of that of that argument right it says, hey, this is why we're doing this. And this number 10 here gives the description it says, this is what's happening and we could say, in production, don't do this but a nice bold text. And, and the install guide already doesn't do it in production so that's that seems healthy as well. And if you know enough to be doing this at all they'll that will tell them why that was Oh yeah, that would. There is, there is another well approach, we can change tutorials, the content of tutorials and use not local directory but GitHub URL so it will grab everything. But yeah, it depends what what people think what is changing. And I just looked at one tutorial I'm not sure how about every tutorial needs this or not. Yeah. Yeah, the, and for me, the, at least the last time I tried to do what you were suggesting Vlad because I've attempted that with this particular these three tutorials is oh we should use the remote repository, but the explanation, particularly on different platforms and different environments becomes much more complicated because we have to teach the user how to push changes back to their fork. And, and whereas this one, all they do is do a local commit and the change is visible, even if they never learned how to do a push. Eight. And, like, since we're talking about this specific piece about Docker installation and tutorials I noticed that our for Windows before it was mentioned Windows and Linux, the content for instance of our run command right now it is different little bit. So, I will also look in this and just. Well, and that's another place where I don't know how we would do don't repeat yourself because there are, there are mandatory variations but it's a good thing to check thanks for doing it because, for instance, this character on the end of the line. That's different on Windows and it is on but the rest of it should be the same shouldn't it. Right and I think it was part of installation guide where we have, like, a little bit different content for windows. I'm not specifically on this on this like a special simple but yeah, I think it is. Docker and Docker but yeah, but I will take a look. So it is like some observations. There is it's also nice to have something simple Docker itself is complicated enough and you don't want to put up too many mental blockades or somebody just trying to get started. It's always the thing to within. You also don't want to set them up to shoot themselves in the foot when they try to translate this so there's the challenge. Yeah. And well there are many different ways of to motivate new contributors to contribute to the Jenkins project. So the ways I explored during last week, for instance, as I mentioned is using some play cataconda tutorials where they can press buttons and everything will happen. And I like put together some simplest way how to run Jenkins and put it on cataconda.com and well it worked. So it can be a Jenkins started, they can deploy, and they can easily like in two steps, see your own version of Jenkins, which is running not on their local computer bottom cataconda cloud kind of right. And we can like play to explore the safe needed of course. But there are so many different ways where we can go. I have one more highlight to show because we got a new tutorial last week from a contributor. In the more tutorial section we now have Jenkins on the IBM cloud. Oh, they tell tell somebody how to deploy a Kubernetes to a Jenkins Jenkins to a Kubernetes cluster in IBM cloud. All right, Vlad anything else on on the Docker topic. No, no, I think just any issues they mentioned, maybe they will be more issues later. So there is still one open issue with the Node.js tutorial. And if you've got, if you're looking at it and have time I would love, love for your you to investigate I could not decode myself while I was working on it last week. I hope this will work. I know it's worked before. I know it's broken now. And I don't know what port mapping we need or what other thing we need to allow us to to use that tutorial it. It's unique in that it, the tutorial has a running process that the user should connect to something like this. And I know it's worked it worked long ago, before we made the transition to, to the, to the, the current to the correct image, it worked with the old image, but I don't, it didn't do the diagnosis to see what was going on. Thank you. I will take a look. So we've got about 15 minutes. Would we like to talk about what's next. Do you want to see a demonstration of table to do tables to this demonstration. I go. Okay, so let's. Vlad is that okay with you make okay we do demo. Yes. Okay, so, so here's what we've got. And this is. Let's drag this one in. And we're going to go to testing machine. Okay, so this is Jenkins 2.264. And it's actually running 30 or so agents, etc. And one of the, the nice changes here is that instead of using tables to do system configuration we're using HTML divs. They say well why would that matter to anybody well watch what happened so I'm going to click configure system. And as always this is a large system it'll take a little bit of time to open while it's opening I'm going to open this in a new tab. And we'll look at some other examples. So here's how it looked in one version prior. So notice the layout. The number of executors line here spans the full width. And they are vertically aligned with each other. No. And now if if something indentation wise happens, it does it in with these dashed lines down the edge to hint to you what's what's being placed below that. So let's let's compare it with the the old system. Notice that restrict project naming has this large step over to the right. I, if I make this window narrow. The user interface becomes fundamentally unusable with the old code. I have to scroll left and right to do anything with the new code. Oh, wow. The next point now it's Android app. It's what One Android app is the next step. Okay, I think, I think that is a lovely that is a lovely thought you are way ahead of what I was thinking but that's a great thought yes Android app. The UI has been adapted now so that I can actually do work in a narrower screen without having to do enormous screen adjustments. And it's, it's quite a treat. Now, the challenge is this is a major major change this poverty term what request spent over a year in review and testing and fixes to various plugins and the fix all the fixes are not yet done as an example. If I remember correctly, this one needs. There are some of the GitHub plugins for instance that don't yet have all the fixes that they need for this. And so there's more to be done. Yeah, here we go we see this one right here that shows us hey that's not quite showing me what I need to see. There's, there's more yet to be done but the UI has become much, much better as a result of this and each time we make these kinds of improvements people get a better experience from the UI. Right now, 2.264 is is being evaluated and if we look at the evaluation comments or the evaluation feedback. We're seeing a lot of noise here. So what you see this cloud 662. That says lots of people have found issues related to tables to divs. And we're seeing those bug reports here that come in. What is going to happen it's intentional that we would do it at this release, because the next LTS is that will include these changes is almost six months away. And we like that that gives us lots of time to test and verify this in the weeklies before it becomes visible to users of the long term support release. So if you find problems, please go ahead and submit bug reports, especially if you can identify the plugin that is not well behaved, beginning with 2.264 like this thing right here. And I think they're already working on exactly those so if we that button should not flow in that location it's a reminder that there's more UI work to be done. So basically, a team is visiting plugin by plugin search for compatibility. Correct. Yeah, that's what has to be done because the table layout was so so widely used and used in such a varied way that it has to be done plugin by plugin. Mark, may I ask, I'll go ahead. No, no, please continue back. Just I wanted to ask Mark about these changes that and fix that was done. Was it related only to configuration or to other places where we can change the size of the screen and it may affect UI. Or is it just for configuration. It's, it's certainly most visible in configuration, but it, it touches anywhere that uses uses tables as a way to do layout of a page. So for example, I can show you one that is an example. I think of something that's not that's in a job and still always except not this one. Sorry, I've got to have some job actually run. So let's cancel the shutdown. And we'll let some jobs actually run. So if we run this one. It's not enabled. Sorry. Find one that's actually ready to run. How about let's run this one. That's a choice. Let's run one of these. We'll just run this one. And what's going to happen is it will after the first run is complete when I look in the history here. There will be a check box or a pick that would let me tag the build. And that tagging of the build use used to use tables to do its UI layout. And because it use tables to do its UI layout. So let's look at that now. It would have been broken. So this see this thing over here that says no tags. Let's give us the look of this thing with that. Nick. That's a that's a table. That's a table layout problem. And it's those kinds of things that will be visible. Thank you. Yeah, now I think, I think the challenge there is this does also touch our screenshots. If we use this an image to show someone how the Jenkins UI looks that this will change that image. And by changing that image. We've got to eventually get to the point of updating those pictures. It will change but it's not so catastrophic because the name of fields keep the same. So the people just realized they all it's split that on the middle and now it's line by line. Right. Maybe the impact it's not so high. Well, and that's that's a good observation. So there are still there's still you I work to do. Plugins to the change. And it's lower impact. And a complete UI rewrite. So for instance, it's not nearly as dramatic as blue ocean was when blue ocean basically abandoned all plugins and you couldn't figure out how to put yourself in. So it's much, much closer to the Jenkins plugin model. So it's almost complete rewrite of the UI and going on has been I mean just the tiles on the manage Jenkins page is a change, right? Well, no, see those actually came. The changes here that were on the few months ago. Yeah, they've been a but that's what I'm saying over the last few months we've had sort of a total rewrite of the UI. Right. Yeah, so, so I guess you're correct in observing that there are certainly many other UI changes. I, for me this was a nice improvement, not so much a major rewrite it's a, it's really a very attractive improvement that we switched having tiled, tiled entries here instead of one long list down vertically down the screen. Oh, absolutely but if you've got screenshots. Right, you're correct. Yep. Yeah. And the, the plugin, if you're looking for new plugins that was totally changed. She used to get this to know it so. Right. Good point. Yeah, that's the and the layout there and the tagging is is new in the last several months. Yeah, correct. Great. Great work. Wonderful. So I think we need a hacktoberfest to just go through all the docs and look at every screenshot. Actually that's not a bad suggestion for a future future hacktoberfest. They're getting close to being done with it I think now. Right. Oh no no no March this this will continue until at least the March LTS. So, so we're at least five months away from from this being. Really, really baked enough that it will be visible to users of the long term support release. Right. So maybe it's just before that that we I don't know. Okay. All right, so we've got about five minutes left. What's next after hacktoberfest. I've got a leg and I were discussing this morning a proposal that will do I'm going to do a quick blog post on major changes that are coming to Jenkins very soon. So I showed you a table to divs. And that one is already done. Now we've got jQuery that will be updated, probably within the next three or four weekly releases. Unfork is an internal compatibility ish risk that most users should not see, but it should not see any threat from it, but it's, it's widespread and likewise this a CG to spring boot is an internal compatibility thing. So for the next probably four to six weeks, I'm expecting weekly releases of Jenkins will be less stable to users than they've been in the past. What about the jcast documentation the last time I looked, the only thing useful was in the read me file for the source code is, but I assume that we plan to it eventually have actual documentation on that. Oh, I think, I think there's quite a bit of documentation right now on the configuration is code plug in. It may have been a month or two that I looked and they may have somebody may have gotten busy in the meantime. Yeah, let's, let's take a look and see. I know that's uncommon. Yeah, so this is what I'm used to as the first entry for the documentation and then if I remember correctly, they have all sorts of guides on how do you handle other things as well. So is this what you were referencing. Yeah. Okay, so that's, yeah, this isn't improved before this was, you know, there was a little bit there and the link to the read me file. Right, and, and certainly there's still much to be done there but we've got linked to the slide deck from Jenkins world we've got all sorts of additional resources that are in there now. It's still very frequently a place for lots of questions about hey how do I do this with configuration is code. Yeah, and then the bigger question I, we name it, but when do we fold this into how you configure your system. Right now, all the old stuff on how you configure the system. And I, I've been thinking in my mind that there's a point that we maybe we, the first step is to go through and say no that you can also configure this with configuration is code and link to that or say you know that might that maybe we don't want to completely switch it because people don't upgrade that fast and, and there will always be manual configurations that Good question. Yeah, I, it's not clear to me on that one that's a good that's a very good question. Right. I don't know and I don't know who's it is to decide as to when we do this but it seems like something you know, five years from now. I don't expect to see it structured this way, maybe even three years from now. So how do we get from here to there. Any other topics we should address today. Where are we with the terminology updates how many of those got done in October fest. I think all the ones that we've identified for October fest stuff. Okay, let's check. So basically master is pretty much gone from Jenkins IO and whitelist. I think master is gone. I don't know. We didn't do any tickets for the slave to agent transition if I remember and I think all we did was tickets for master to controller so I'm, I'm pretty sure that Jenkins that IO probably still has some references towards slave. Mostly cleared up though my, my experience has been most of them on screenshots, where the soft allowed there is software that is still in fact, there's been fairly new software that's used slave. Right, right, we've we've still got lots of places in the source code, where we need to where strings that use the word slave need to be need to be fixed. We have what we have, and we have stuff in the UI that where they're still we're slaves still shows up a couple of places, including new stuff so I think also now documentation sometimes there is a reference to master as GitHub branch, and there is separate effort inside GitHub open source community. What are we doing about is GitHub master changing. Well, so command line get has now stated that they eventually intend to adjust their default. But they haven't done it yet. But when you run the get for windows installer today. It already asks you, what would you like as your new default primary branch. So many people use master before you could choose main or trunk, or, and they offer several suggestions now that just barely arrived in. I think it was get for windows to 29 within the last month. But but it is it is arriving. So, right. GitHub making that change is, I suspect, even bigger. Right, because they've got a lot of places they'll have to worry about. Really. And that they're making it flexible so it isn't like it's a straight replace this for that. Right. Yeah. All right, the question is that what, what is the Jenkins project going to use I assume that we're going to choose one term to use throughout the project right and not even been discussed yet. Yeah, I don't know. And I think it's a good question. I have no idea. Right now I think we've got enough issues with this one and this one, master the controller and slave to agent that we are. We've got years of work potentially there before we ever consider renaming our branches. Right. Did we see half as PRs for whitelist and blacklist. I don't recall any I did not create any for this one. Okay, there aren't I don't think there's as many instances of bad. All right. I guess I created some of one of PRs for changing whitelist tool to allow list. Okay. So a little bit. Yeah. Excellent. Thank you very much. We will meet again next Monday. All right. Thank you. Bye. Thank you. Bye everybody.