 Hi, everyone. Welcome to the platform special interest group meeting. Today is our 7th meeting in the row. And we have some topics to discuss. Today, we have someone or Mark Wait, Ramon and Adrian on the call, maybe somebody else join while we have a discussion. And yeah, I'll probably just share my screen and start from there. Okay, do you see my screen? Yes. Okay, that's cool. So if anybody wants to join, we have a participant link posted in the Guinness channel. And as usual, we have meeting notes document and here you may find links to the today's meeting notes and also to the recording, the session will be recorded and we'll publish it later. Today, we have three topics proposed for the agenda. It's Java 11 support status update. Then, job 217, it's about experimental organization on Docker Hub for delivering images. And I also wanted to spend some time to talk about Windows Slaves plugin, which is no longer Windows Slaves plugin. And yeah, I think it was some discussion. So does anybody has any other topics for the today's meeting? Yeah, we have not Mark today. Sorry, we don't have Alex today on the call and we also don't have for durgados. So yeah, believe you'll stick to Java 11. And yeah, probably I'll quickly summarize what we've got for Java 11 and then we will switch to action items. So last week, as we discussed at the previous meeting, we announced support preview availability of Java 11. So there is a blog post posted on Jenkins IO, which provides some information which explains how to run Jenkins Java 11 in Docker and in the Word files. So we are fully alive. And the first milestone for Java 11 is completed. And our next steps is to work towards general availability and to fix some compatibility issues, including pipeline support, including Jagsby bundling Jenkins code and other things. But generally, the current version is already available for usage. And we've already got some feedback in the community. And actually, this Tuesday, we had a Java 11 support preview meetup, the Jenkins online meetup. So Firefox still shows everything in Russian for me. Yeah, I'll probably switch to Chrome then. But yeah, we had a meeting on Tuesday, the Baptiste and other members of Java 11 support team presented the current status provided some guidelines how to work with Java 11. And if you're interested, you can just go to the meetup page. And there is a link to the YouTube recording. So you can just watch that. And there are also some presentation slides, we will link it here soon as well. So one of our projects Java 11 support is for your life and available for usage. This is probably the main update for today. And if you'd like, I can speak to the pipeline status on this. Oh, you you see today, I was going to ask the question, Sam, well played. Yes, I wanted to hear all the pipeline status what have you learned? All right, so we've learned a lot of things that it isn't. It doesn't appear to be truncated serialization. It doesn't appear to be a significant change. It doesn't appear to be data omitted. That's causing failures. There are some subtle changes in the binary format as we knew. But the the errors we're seeing are highly reproducible. And putting putting inputs and outputs side by side, there looks to be very, very little difference. But yet, there are failures still. So we've basically we've we've dove in quite deep into this. And we're down to the point at which we are now trying to pick a needle out of a haystack out of the code changes within J boss marshaling at this point. And I would like to throw the door open for anyone who might have ideas about how to get this to a more straightforward solution or quick quick or clever solutions. To take a look at Jenkins 55174. Because I think this is one at this point where any eyes on this would be helpful. I've got basically I've got binary outputs before and after I've got thread dumps before and after. If you dip the two, you can see what the difference is. It's not huge. There is something in here is is causing a subtle breakage. Reading the program very reproducible, even in the most trivial case. Yeah, and we also heated in the plugin compatibility tester. So this is a big red flag. I wish the news was yes, we fixed everything. It's beautiful. It's golden. Paths are cleared. But as we know, sometimes when dealing with complex code, that is not how these things play out. We've at least been able to wipe to eliminate a large category of changes. We think we think on the basis of the evidence that it is something subtle specifically in the handling of read resolve or field deserialization. But the changes here add up to a couple thousand lines of changes in a very complex code base. So basically, we're, we're at the point of trying to dig in one line at a time to look to see what it's doing individually. It's a kind of display mode. Yeah, I wasn't going to characterize it like that. But I know you guys can hear a little bit of frustration in my voice right now. Yeah, would it help if we got a Jboss remote and machine developers on the call? And yes, please. Contact anyone who's active in this code base, please put them in touch with me. I would love to have a chat with them. But I promise to avoid using any particularly offensive words to describe my experience is debugging this. Well, it's a low level library. So it's not supposed to be easy for debunking. I've seen some comments in the code base that indicate like, they're like, this is delicate code. Are you sure you've tested this? So I think it's, it's known even in their side to be very complicated and very something deep down in the dark scary internals that you don't want to touch without due caution. Okay, so I'll try to follow up on that because yeah, I have some idea how to get this feedback. But yeah, I will try. Yeah, I think we need, honestly, we need one of them. I can, I can do this, but it's like, it's going to be days and days and days and days and days of going line by line by line at this point. So it may be quite complicated for the Christmas time. Yeah, you can look at that. I mean, you can look at the program.dat. You can look at the, the thread dumps. You'll see the thread dumps look basically identical aside from line numbers. Yeah. So yeah, we'll definitely investigate that. And actually, it's really important for the GA release. In preview availability, we offer a workaround, but they see she isn't fully solved by the workaround. So we hit it a few times, plug-in compact tester. And effectively, this is one major blocker for any kinds of discussions of GA availability in Jenkins. Yeah, and this is not, not an easy fix. Well, it's not an easy, easily debugged issue. I mean, we hit everything else that we could from pipeline side, we've resolved. Most of those were fast and easy. It's just that solving the fast and easy stuff revealed the one that is really not easy. Yeah. Some, it might be useful to create a GitHub wish to Jboss marshaling. So maybe they, we could get a response. So if you could initiate this discussion, it would help me. So but I think that they prefer to accept them via Jboss jurors submissions. Okay. Well, maybe if you could create a Jboss issue to them. Yeah, I can do that and see if I have access. And just just to give voice to that, I've my experience with working with the command line Git developer on Windows was and with the JGit developers was awe inspiring how much those people wanted to help the Jenkins project. It was it truly surprised me. I felt like I was coming in from nowhere asking for their help. And they immediately kicked in and said, Oh, yeah, let us help this way. So, so yeah, so we're asking for help from other experts. Yeah, I totally second marks experience. And here we definitely don't ask a stupid question. And really good effort to investigate it on our side. So yeah, getting some help would help us. I'm glad I raised the flag in this one. And that would be yeah, I mean, if we can get an expert on this, they may know where to drill in for this. Because I think at this point, it's either bad or trying to parse the code base ourselves. Well, in some cases, it's just I've added the link to the profile of the main developer. That seems like there's basically one. So Lloyd. Ah, Lloyd. Okay. Oh, he's a redheader. Okay. Okay. So yeah, I know how to reach out to him. Okay. So yeah, I think this is one of the major issues we have. Yeah, let's take a look at what else we have on the table. So or maybe some of you have other status updates. That's the big one for me. I mean, this this is this is the boulder that we've been trying to roll out of the mountain pass for the better part of a month now on and off working with other stuff as well. Yeah, right. And thanks a lot for doing it. I wish it was more straightforward at this point. No, I did start exploratory testing of JDK 11 with my my test environment, reported something in Gitter, but I don't have anything substantive to report other than I was surprised when a bunch of my pipe pipelines seem to hang with no CPU usage. It may be that it's an existing bug in Java eight as well. I haven't I have no evidence that says it's specific to Java 11. Right. You're highlighting exactly that I don't have anything else to report except that yeah, I saw something odd. I'll investigate further and ask more questions later. Yeah, right. So if you have thread dumps, it would be helpful. And even if you have suspicion, it would be really nice if you create a Jira ticket. We at least know about this issue because it's all if pipeline hangs, most likely it's related to pipeline. Yeah. And yeah, then it's better to have a tracking issue for that. Will do. Thank you. Okay, thank you too. So let's take a look at what tells we have on the table. Over the last two weeks, we spent a lot of time to get plug-in compatibility testing over the fence. So if we take a look at job 211, am I still screen sharing? You are. Oh, that's cool. So yeah, in testing, we have Google Documents testing status. So just to summarize the thing, we spent a lot of time on development tools. So it's not only plug-in compatibility tester is also acceptance test harness. So we discovered that there were some issues in merged commits in acceptance test harness and Ramon and then Ortiz spent a lot of time to get the things right. But it seems so that it's much better now. Is it? I'm not sure you heard your question, Oleg, but how is the test harness working? No, I think it was cutting off a bit because I heard that we worked on it and then I didn't hear your question. Yes. So there is now one hopefully last PR because one has been merged earlier today on ATH itself. Basically, we think it probably comes from a Selenium 3 change and something gets cleaned up badly. And it's failing randomly a few tests. So if you look at Jenkins Core right now, there is an open PR, which I think unfortunately failed again for another reason earlier today, like one hour ago or something. And the thing is the PR from Ramon, I thought twice and not call him Raoul again. So was still failing for weird reasons earlier yesterday, but still was green on once merged on master. But anyway, the status quo is that now it's much better because now the master branch doesn't fail immediately because of that missing set Java.sh script. So PR should be running fairly better if hopefully greatly better and possibly even green or at least not red for totally unrelated reason basically. So the story is not at his hand. And anyway, I would say that at some point, we probably will need to think about all this twice or more, because we all know that ATH is slightly flaky or flakier than core tests. And so it's not great with regard to the speed delivery speed for core PR scores changing. We've seen a lot of people included newcomers like I remember that one from Gavin Morgan, who's been spending a lot of time trying to debug something that was totally unrelated and was actually related to the thing we fixed. And so they're like every single PR that were that was were open the last few days or the last week or so even before we're all failing for unrelated failures. So now it's getting better. If you look at Jenkins, if you click there and you can commit, you should see that now there's some green but yeah, this is not a finished story, unfortunately. Yeah, and we haven't enabled ATH for Java 11 yet. So we're still building on the Java 8 in the core. Yeah, but we still yeah, before that, there was never ever a single failure as far as I know on ATH. So I do not really think it's coming from our changes for Java 11. I more I think it's coming more from Selenium 3 something. Yeah, well, even I was not really sure because actually if you look at the pinned down version of ATH, we were using before it was already apparently Selenium 3 basis. So yeah, it's it's really unclear. It's well ATH status right now is known to be pretty special because if you look at ATH core right now, master branch, there are 72 failures, and it's the normal state. So obviously, this is well, something that kind of becomes visible on the master core Jenkins core. I mean, so yeah, we might want to investigate and spend some time trying to level up the flakiness of ATH itself at some point, I think. Yeah. I think it's easy because, well, Oliver is really, really capable. I mean, so I think he spent a lot of time already trying to do that. So it's not that easy, I guess. Yeah, right. And another update is that we have a Java 11 support in RAM ATH step. So we have integrated the changes needed in the pipeline library. Yeah, and if you open the failures related to the PR you just approved, basically, you see that there are other ATH failures that are unrelated again. So that's why I was saying it's not a finished story. Yeah, it's always fun. But well, we will figure it out. So is and as a as a non ATH user, have you found that ATH is helpful in in detecting real problems? In addition to the what I might call false positives or in this in addition to the misleading things? Has it helped us isolate real problems? It's hard. It's a good question. I mean, okay, so I heard it wasn't an obvious immediate. Oh, yes, it's that there's some question there. Well, you know, my I think and I don't know what other thing, but there are so many known about failures, that you have to be, you know, kind of an expert, like Oliver is to know, okay, that one is failing, I know why and it's normal. That one is failing. And that's a new one. And that's not normal. Yeah, that thing is really not welcoming to new to new commerce, basically. Yeah, we all need to clean it up eventually. Well, it's not feasible. I mean, the probably the thing to do here is just to ignore a bunch of things. And once we get something green, we're, you know, try to reopen progressively. But the state right now is, I think, I don't know, unusable for anyone that's not being working on, on that cut base forever. Yeah. So there is a thread from Oliver in the developer family, please. It's about future of each or something like that. Even even from Lucy, I think he was typical. Yeah, that was it. It was the, it was the second link on your list on your top. Okay, good. Alt, Altback. Alt left, left. Yeah, right. I think that perhaps all PRs injecting score are failing because they need to match with the master to get the new changes in the central files file. That's fixed the problem. Normally not. Because normally what's the current behavior is that, so if you look at the statuses of PRs, this is there, there's that thing called PR merge. That means that PR are merged by Jenkins and then tested. And when you merge something on master, everything gets rebuilt against that new master. So if not, if not yet, it means that the CI doesn't get that IO is probably full and not building yet, but this is the normal behavior. This has been the behavior for like, last, the last few months, if not year, because it's been created also a lot of frustration among developers, because each time someone merges a PR on master branch of the core, it, it's, it kills the CI doesn't get that IO for hours, because we have to rebuild thousands of PRs. Yeah, unfortunately. So that, that's a good thing in that regard that you're talking about, Ramon, because indeed we rebuild the PR that, that got failing for an unrelated reason. But that the done side of that is that indeed, we rebuild everything each time. And when things are already green, it's just a waste of time. Yeah, somewhat. Well, the waste of Azure credits for start. Supposedly more a master indeed of priority. If we were able to say, okay, plugins, for instance, plug in new PRs would be, you know, going through with higher priority instead of instead of the things that are already in the queue, probably people wouldn't complain so much. Because think that God rebuild, you know, during the night for something that got filed like month or years ago, nobody cares about anymore. It's just that that's probably one that frustrates people the most. Yeah, we were trying to clean up pull requests together with Daniel Beck. So we merged dozens of old pull requests or closed them over last year, but we still have more than 100 open PRs in Jenkins core, though 50% of them are several months old. So, but we still improve a lot. Okay. Anything else about acceptance test harness? Yes, you know, so regarding plug in, plug in combat tester, or last week, we also spent a lot of time testing recommended plugins and plugins appearing in Jenkins installation results. So you may see the status here, actually, we tested more plugins because there are cross the dependencies, etc. And we plan to spend more time on testing guys. And actually, we discovered some new defects using plugin compatibility tester. Though the most of the work was actually about fixing plugin compatibility tester itself. Because we discovered that there is a lot of compatibility issues, a lot of missing features. For example, PCT wasn't compatible with incremental releases till we started working on that. So we needed a lot of patches just to make it passing. But after that, we actually got a number of results. So for example, PCT discovers this null pointer exception issue in pipeline support, there are also other issues we hit, for example, in metrics plugin, there is some code which is not compatible with Java 11. And yeah, there are other plugins which also require some fixes. And last but not least, there are development tools. So sometimes when we need to run against Java 11, we need to update dependencies, especially PowerMock Makita. So when you test using mocking actually the needs, sorry, any plugin using mocking needs update before testing for Java 11. But well, we are moving forward. And we still got good additional coverage. So yeah, we can test more nowadays. And the plugin competitive tester is now a tool available to all plugin developers. So anybody can take it, this experimental branch and then just get the results. Adrian, would you like to add something about PCT? I think you covered mostly the subject. Also, you mentioned the branch, but I think that's mainly everything is merging master now will be so niche. So even even the master branch should be available to test for JDK 11. Yeah, we have two standard pull requests here. One is support of running PCT against incremental releases. Yeah, the one that's not really related to JDK 11. Yeah, because it fails on Java 8 as well. Yeah, since one more plugins migrate to incremental mode. Exactly. Well, we need to update us up. So self dependency is a resolution I guess, I guess it's also not related to Java 11. We just hit the issues with some plugins like J unit and structs, due to whatever reason, effective forms generated for the recent versions, they include self dependency. So J unit plugin depends on J unit plugin. And no one day it crushes during the Maven build. So we've had to apply some hugs to prevent that. So it's also for integration. Yeah, we had all other secret dependencies that were not that straightforward, but that were also resolved by the work of Oleg. So yeah, I'd say the PCT now is more usable to validate plugins and should be used a bit more by plugin maintainers, I guess. Or rather, it's for JDK 11 support or not. So Oleg, where would Oleg or Adrian, where would I find more information? I am, I am a PCT non user right now that I should probably become a PCT user. Where can I find more information to teach me how to use PCT effectively? Surprise, there is documentation. Excellent. Yeah, yeah, when we were working on JEP 200, our initial state was so that PCT wasn't compatible with Jenkins 2.x at all. And there was no documentation. But over the last year, we improved it a lot. Because we firstly had JEP 200 that then we had Evergreen and Essentials Test Framework. Then now we have Java 11 and PCT got improved a lot. And there are some Java 11 specific guidelines. If you open the page for Java 11. Oh, it should be automatically creating Jenkins for me. Okay, so I'll just find this page. It was also created over last week by Baptiste. So yeah, this is a page which includes a lot of stuff. And yeah, effectively, it contains critical links like how to run PCT with Java 11, how to run ETH with Java 11. So just refers documentation and external sources. But yeah, you can use it as a main landing page if you're a developer and want to do something about Java 11. And if something is missing, you're encouraged to actually leave a comment or something so that we know what's unclear or whatever, obviously. Yeah, thanks. Okay, so it's if I use the developer guidelines and specifically follow that link to the plugin compatibility tester document, that should take me through getting started as a completely inexperienced PCT starter. Great. So usage of PCT is really easy nowadays because firstly we offer Docker images. So if you want to just test your plugin, it's something like that. Or you can check out local sources, etc. And if you need something specific, you can use PCT as a CLA tool. And that's also documented here. Yeah, I'm I'm I'm worried more about an incremental unified pair of plugins. So I suspect I need the pull request that adds incremental support. Yeah, you need it. But yeah, hopefully we'll get it in the greatest soon. Okay, great. Thank you. So once the pull request must be have continuous delivery of Docker images for CLA for CLA it's a bit complicated because there was no releases of PCT for a while. So last release one was in March 2017. You probably need to recover the release flow here. But okay, that's what we have. So yeah, you can just take Docker image for starters. Right. Yeah. And by the way, if you use Java 11, maybe it's better to not use the Docker image because I'm getting her from somebody. I'm sure. Okay, so we still have one issue is PCT in Docker because there is sorry, something goes wrong. There is one compatibility issue with PCT and development tools. So in some cases, maybe in short five plugin just precious within the Docker image. And sometimes it crashes in the local run. But in Docker, it gets reproduced almost 100% of time. So we will need to fix that and just looking for the ticket. Can it run efficiently? So it's sure five 1588. It's what we already fixed. Oh, yeah, PCT sometimes crashes on Java 11 due to model read errors. So this is something we still need to investigate why it happens. And until it's happened, it's better to run PCT locally for Java 11. Yeah, so effectively, we'll need to do something and we have issues with upstream Jakarta models. So I'm not sure how we'll approach that. Okay. So just use PCT locally for Java 11. It's important for now. Okay, that's the current status. One of the interesting things is that we started getting some feedback from the field. So there was one issue report this week for Java 11. But yeah, technically, we still need to clean up this history. You may see that there is a bunch of tickets we need to do for the J availability. But the most of these tickets are about development tools. There are not so many regressions we need to fix so far. So yeah, maybe it's a matter of we still really able to deliver Java 11 support in GE and we mostly rely we mostly depend on the pipeline support fix right now. Some other beats would be nice to fix as well. Okay, anything else about Java 11? Nothing again, think of. Okay, yeah, we have something like 15 minutes left. So probably, we can glance through all the topics. Okay, experimental support of Jenkins organizations on Docker Hub. Last meeting, we had a discussion that it would be great to somehow automate the things and we have a number of action items. So if you take a look at the previous meeting, could be agreed that we actually need whatever Jenkins for eval credentials on CI Jenkins.io. So Oliver here has created a user. I have created JEP in order to document the flow. And currently this flow is available for evaluation. So if you open a JEP 211, I should really start closing tops. Okay, JEP 217. So yeah, JEP 217 is a new JEP which actually documents the current behavior and it includes a sample pipeline script, which is which can be reduced. Now there is one update panel here. And actually, this is an important topic to discuss about this update. So this update includes two bits. One is about guidelines. It just reflects what all of you has did has done on the infrastructures and whomever wants to try experimental deployments from CI Jenkins.io, you just need to follow these guidelines. I'm currently creating a patch from one of my Docker based repositories. And generally, everybody can contribute a patch. And we need to dispatch soon because there is ongoing story about experiment about multi-architecture Docker images. So for ARM and for other platforms. So there is an email thread about that. And we actually need to get this experimental infrastructure over the fence. So we get Docker images over the fence as well. I hope you will finally get it done because it was around for several months already. So we will need to do that. And yeah, the second part of this topic, which is quite unfortunate is about Jenkins for a while. So the story behind it that in August, we were discussing the name, we agreed to have a name Jenkins experimental. But then it appears that Docker Hub doesn't support organization names with dashes. And yeah, after that, we agreed to use Jenkins for a while as a name. And last week, there was a feedback from Liam Newman, but Jenkins for a while implies some references to Jenkins for and since we don't plan to release Jenkins for any time soon, probably it's confusing. So there is an open question, how should we name it? And if somebody has any comments or ideas about that, it would be much appreciated. Jenkins lab. It's for the film. Yeah, for fun. It's a good idea. Jenkins lab Jenkins. Yeah, I'm a little hesitant personally on that one because of possible association with a certain source control vendor who hate ends whose name ends into the three letters lab. Really? I never thought about that. Yeah. But yeah, isn't the problem like with anything that uses the digit for that it may have the same objection from Liam about version exactly. So Jenkins for fun, even if it's fun, but yeah, it's, it's still a dozen parts. Yeah, because it's I mean, there's there's two possibilities. So experimental would be just you're replacing that by an underscore, I believe. Yeah. Then there would be Jenkins for eval, but with f o r. Right. Yeah, and the idea from Malin was that yes, his idea was to have Jenkins futures. Yeah. Okay. Yeah, that's that that has the same inference, right? That this is something coming? Yeah, let's you have economic degree. Well, then it's like Jenkins coin. Jenkins coin. Jenkins insert, Jenkins coin. Now, I think, I think Sam's comment in the chat window is brilliant. Jenkins cannot come up with a name for awesome. What? Sorry, I didn't see the chat. No, you should not put it in the notes. I think Sam put it in the chat specific to the star spring IDs. Well, probably we'll hit the organization name of limitation. Right. That's incidentally, incidentally, you're trying to give your load testing Docker hub. Thank you. So this one knob. And I believe this one also knob taking the comments from me. Could we not just call it like Jenkins? Jenkins unstable or something? Yeah, or Jenkins next, or let's see the that's a good, good point, the or, or even Jenkins lab in Cura. Or wait, Jenkins bleeding edge. Jenkins, don't use it. Okay. I'll do that. It's always getting a little bit. But I like the Jenkins next and unstable. Yeah, the problem that, yeah, whatever we do, it looks Yeah, I mean, I mean, we probably cannot, you know, go without an underscore so that it's kind of clear because that you can't use underscore as well. Really? Yeah. I like Jenkins next, actually, because I think Jenkins unstable might make us the bottom some jokes. And I would rather not help us up for that. Right. So but is is Jenkins next a safe thing? I guess it's, well, there's so many, so many vectors for the evolution of Jenkins, because it's such a substantial project is Jenkins, I guess Jenkins next, we would envision as an umbrella, anything potentially, no matter where it is, could go under the Jenkins next umbrella. Eval for me has less of a less of an inference of, oh, it'll be released soon than Jenkins next does. Well, Jenkins next may cause an assumption that it will be released, which is not exactly true. So it may be released or it may be not released. But well, Jenkins next is something like Jenkins futures. So yeah, why not? Right, I guess if you're right, if if if Liam's Jenkins futures would be okay, why not then Jenkins next? Yeah, exactly. I've just had a look locally. Are you sure those cores are in forbidden? At least it's my understanding. So he is very interesting to read thread. Well, yeah, Docker hub community feedback gets a lot of notification. Yeah, so underscores are also prohibited as far as they can tell. We can try to create it if you want. I just did. I just did. I'm actually pushing right now, but it seems okay. Yeah, maybe they changed something, but is it an organizational repository? It's a repo. Yeah, a repo you can have understood course. Oh, you mean the York? Yeah, the work. Okay, Jenkins of all. I'll kill it. Oh, yeah, only lower case letters and numbers. Maybe just well, yeah. So for me, Jenkins it given that Jenkins futures was suggested by Liam and I like to work next better than futures. I'm biased towards Jenkins next. Okay. Any other opinions about this? I would say given it's been here for month, we shouldn't rush it and just did go through the development list so that we get more ideas and possibly way out because well, we don't want to rush that and find another name that's going to trigger the same level of ideas because as far as I can tell, even if if Liam's feedback is interesting and possibly to be taken in account, this is a single person feedback. And so I'm changing everything for dozens of people or a dozen of people plus blah, blah, blah, you know, everything that's going to be changed. And given again, that's been there since at least last June, I don't see any reason to rush it. Yeah, no rush at all. So we're interested to expedite the things a bit because to go fast enough, but then like choosing something, I mean, just making sure that we don't aim at choosing something right now. All right, we don't aim. I was just collecting feedback. And actually, if you follow the guidelines defined here, it should be okay, because with current job explicitly required that you use docket hub organization environment variable. So once we decide to migrate, we just check it, change it in the pipeline library, and everything should continue working because in local hub, you can just create new repositories by push. Yeah, anyway, I mean, we've been changing the official repository twice already. So I don't think changing the experimental one is going to be any kind of issue anyway. Yeah, it shouldn't be as long as we don't delete what we have. Well, I mean, if you've built your production, you know, on top of Jenkins for error, then you're, you haven't done that. But yeah, for example, for Java 11, we start from. We don't, I don't want to be offensive, but we have no time to waste or to lose on some people that build their things on clearly experimental things. So yeah, okay, I won't be going to particular examples. But yeah, I agree. So my action item is to just call the developer madam piece and link to this naming so that we can get some action items done. Okay, last but not least in the agenda, can we move on? Do we have only a few minutes left? No, I think we should like shed some more. Okay, so what's the next step, please? We are waiting for your next idea is then. Oh, or back to you. Okay, since no specific proposals, how to set track a bit more. Okay, let's talk about slavery then. So yeah, we had a long, long standing in Jenkins about cleaning up the old trauma because all agents were called slaves before Jenkins to do zero. And actually, there is still a lot of variance, various slave usages and documentation. And I find that I got two pull requests over the fence. So one was about renaming slaves to agents in Windows slaves plugin. Yeah, so finally I landed it in just more than one year. To get it, I merged. Well, okay. And what I wanted to actually tell you that I renamed the plugin, so it's not longer called Windows slaves plugin. Now it's called we may Windows agents because one of the major concerns, which naturally leads to extremely high installation numbers, is that whomever wants to use Windows agents, they try to install this plugin. So we have almost 15, sorry, 150,000 installations, though I believe that almost nobody really uses this plugin because well, in order to use this plugin on recent Jenkins versions and on the recent Windows versions, you need to firstly enable BMI in your windows, then you need to enable decom that you need to reduce all permission settings so that Jenkins can really connect over BMI to your machine and install Windows service. So it's kind of not trivial to pass through all the security introduced starting from Windows 7. So I believe that this plugin is actually not used on the most of the instances. And finally I decided that one of the good first steps to finally rename this plugin at least. So now it's called BMI Windows agents, and I hope that the installation number will start dropping at some point, though this plugin was originally detached from Jenkins core. So as any other detached plugin, it relies on the fact that users do not install plugins that require called Jenkins core versions. So it was detached around 1.4 80 or so. And we still have a number of plugins here which use all the Jenkins core versions as a dependency. So it is being installed automatically when somebody reinstalls such plugin. But anyway, one step forward that direction. And the same SSH slaves was renamed if I recall correctly. Oh no, it's still SSH slaves. But I believe we will rename it to SSH built agents or something like that. Unfortunately, we cannot rename it to SSH agent because SSH agent means completely different thing, not Jenkins agent, so we will have to use something. And yeah, this was my update. Okay, now I just need to rotate the XKCD links from Batista. Okay, that's all for today at this. At least I don't have any other topics. So my question to you guys is whether this format is good or whether we need to somehow change the format of the meetings and whether we want to add some more topics for the future. No, I think it's fine. It's the regular checkpoints, so I think it's fine and we'll just add things as we need it if someone is requesting it, I guess. And for me, the Google doc to capture meeting agenda proposals and then tracking the notes in the Google doc feels really good. I like how that's worked out so far. Oh, like, let's please continue it. Okay, so we still look to the current process. And yeah, then maybe next year we'll discuss something if we have more projects, but now we have three ongoing projects, so it should be good enough. Okay, I guess that's it. And thanks to everybody for participating. So we have a Christmas break and our next meeting would be it would be somewhere around New Year, I guess. Yeah, I assume it's, yeah, three days, I guess. I assume it's, yeah, three January, right? January 3rd is scheduled and first or second week of January, I suppose, yeah. Is it already scheduled for Thursday, January 3rd? Is there any reason not to just hold to that schedule and those who can't attend, don't attend? Yeah, I think that's kind of a good idea, yeah. Yeah, I think we just keep it and then let's see. Great, so have good times, everyone, and particularly, particularly your leg. Well, I will definitely have a good time and you will unlikely see much of my activities over the next month. We are going to have a good time. You are going to have to have a partly good time. No, no, a busy time. I'm going to show you it's a good time, you know, but it's a busy time. But overall, the experience is generally very good. Okay, noted. Yeah, we as humans generally remember the good thing. That's why we didn't extinguish the whole human race, you know, in three generations because, yeah, if we would forget, not forget, then we would have killed ourselves. Okay, on this note, I'll probably stop the broadcast. Right, so that's kind of an advertisement for people if you want to attend, they could see that it's not just boring. Well, yeah, next time, let's do something more. That's fine. Okay, thanks, everybody. Bye-bye, everyone. Thank you guys. Bye. Cheers.