 Welcome everyone. This is the Jenkins Platform Special Interest Group. Great to have everyone here. Let's take a look at our agenda first. And we're going to talk through the agenda after we've looked at the agenda will then work work on the items on the agenda. So, we'll talk through open action items as one. Then adopt open JDK as a potential replacement image base JDK for Jenkins images. Talk about the current status of that. Then the evaluation of adopt open JDK open J9 as an additional image. Then discussion on Windows. Discussion on Windows installer. October Fester and I assume Alex that one's you and possibly Oleg. Yeah, I'm. Okay, great. Then October Fester results. Plug in installation managers on our agenda. If Natasha arrives we may will have a deeper discussion. Otherwise it'll just be brief. Mac OS native installer deprecation topic with Oleg. Potential topic on broadening platform support for Docker images. Then mac OS native installer updates. Nothing. It's the same as mine. Oh, good. Okay. All right, so we'll just put that. I just want to keep that link and we put it underneath yours. Great. Thanks Oleg. All right. Anything that we've missed that needs to be added to the agenda. Maybe we could put a high in the list so that we finish this organizational path and then switch to technical topics. Because I see how trouble is in the middle of a installer or whatever topics. I like that. That's good. Let's lead with October Fester. That way. Yeah, it's also it's a great story. I think so let's do that. All right. Excellent. Thank you. Okay. So open action items. I'm sincerely sorry. I still have the open action. It will probably remote remain open for another month. To open a jet for a process to choose how we do Docker operating system support and platform selection rules. It's we're making progress by doing the work, but we need to also get a process described that we can use to select. Oleg anything you want to report on the windows support policy. Nothing specific except the fact that I'm going to do it. This week I spent some time to the browser support policy. And I think that I will do window support policy in a similar way. So probably even without Jeff. The window support policies like the more controversial than the web browsers. But yeah, I think that having a draft. Great. All right. Alex anything you'd like to report on the to do on windows installer code signing. Oh, I noticed that the CDF ticket is resolved. Congratulations everybody. And that we've the release automation project is proceeding. We are doing some reviews here and there. We did a lot of enhancements for this automation infrastructure. Now I'm trying to document it a bit and review the main pull requests. But it looks pretty good right now. So yeah, the certificate is yet to be obtained. But at least this major work is resolved. And look at it. The certificates. The certificate not yet obtained. Is that blocked by any, any tech, any legal hurdles. No, it's just a technical process. So we spent some time today or it was already on the call to request the certificate. I mean, I firstly, yeah, CDF set up a legal entity. And that's why it took so long because we needed a special legal entity for continuous legal foundation. Then they created a digital search account. And after that, we were able to do the request for the certificates. So these steps are done. And now we just need to get a real certificate. So it should take some time, but there should be no obstacles there. And another optical obstacle that we had for Jenkins release automation. It's my course packaging. We will talk about it later. Yeah, it's under this. Great. Excellent. Yeah. Alex, anything you needed to report on that topic? I know that pretty much ever. But I didn't see any stuff getting into traction. Excellent. Thank you. Thanks very much. All right. Oh, like October fest. Do you want to share your screen or do we want to just. You can just open the email because I don't have so many things to show. All right. Yeah. Just quick summary. So yeah, we had October fest. Yeah. If you just open the first email, there are some statistics published. Actually, I have a bit more statistics as a draft blog post. But yeah, there is more than 100 new camera contributors. And it was a history high months for Jenkins. So we had 915 unique contributors and almost 200 companies contributing. So yeah, it's really high for Jenkins. And let's see whether we can retain these numbers for the next month. Probably not, but we could always try. Yeah. Regarding the rest. Yeah. We have 250 October fest pool requests. So these are confirmed ones. We don't know who exactly participating in October fest. So it's just an estimation. I think October fest team to provide some organization level metrics, but yeah, no guarantee. Last year they decided not to collect anything. Regarding the changes. I put some highlights in the list. Yeah, you can see that there are changes here and there. Now, what is matter for the platform special interest group? Yeah. It's just the, a lot of really like in sports documentation updates on bombs. Then we had changes in Jenkins configuration as code plugin. So hopefully we will officially move it to the sec umbrella. But yeah, there is a lot of documentation and a lot of test framework improvements while taking the ongoing discussion about Jenkins 2.199 probably not enough, but at least we are getting somewhere. So yeah, there is a lot of changes there. And of course, there is Mark's platform library plugin, which also got a lot of improvements during October fest. Yeah. Yeah. What a great story that is. Yeah. Thank you very much for leading that effort. That plugin documentation story in particular is quite amazing. All right. We had a crucial infrastructure challenge with the wiki, but, but now it's turned into something very, very positive as they're getting much better plugin documentation in a much more maintainable location. Yeah. And tomorrow we have a meetup to talk about it. Right. Just some of the interesting. Thank you. Thank you very much. Yeah. So, basically that's it. One of the follow-ups. I'm thinking about doing future projects beginning October fest. So one of the takes away take a ways for October fest that future projects really help to focus the effort. So I'm thinking what if we do it on a regular basis, for example, future project of the months. Yeah. So I'm thinking about the plugin documentation or maybe docker packaging or something like that. So just highlighting a particular area and see whether we can facilitate contributions there. So this is, sorry, I missed. I didn't catch your second set second idea that was plugin documentation. No, docker packaging. Oh, let's see. Oh, docker packaging. Good. Yeah. So when I'm going on that, there are people who are happy to help these reviews, or at least who have time for that, then we could try a kick off this future project thing and see whether we could address SQLs because for me, docker packaging, yeah, we have a lot of pen and pull requests and it's basically in my hall of shame because I have no time right now. But yeah, I'm getting there. So maybe by facilitating contributions, we could resolve these bottlenecks. Right. I like that. I like the notion of increased energy just by promoting, hey, this month's featured project is this very good. Just something to think about for the moment, but yeah, maybe after Jenkins, one does settles. Yeah, we could try something. Great. Thank you. Anything else on, anything else for me? All right, next topic then adopt open JDK hotspot. So Jordan, thanks very much for being here with us. I'm, I don't have any progress personally to report on adopt open JDK hotspot changes. I haven't evaluated that. I use my time to evaluate open J9. But the transition poll request is, let's see if I recall correctly, I haven't submitted for this one. Do you recall the number on that one by chance? I do. I do not. It's a good question. I thought that we were still waiting for a poll request with that proposal. Oh, that's right. Yeah. I don't, I don't think that has been created. Jim's on vacation. So some, there hasn't been too much progress on our end. Right. So, so it's this one, it will likely wait a month. Before significant progress unless the hack fest at DevOps world makes some progress on it. Is it a subject for the hack fest? I don't know that it's been proposed. It's just sometimes those hack fest topics adjust and, and change. Yeah. And so I can also say for sure that it hasn't been proposed yet. I don't know if anyone wants to edit the list. Please do so. That is, let's see the date for that is December 2, 2019 in Lisbon, right? Right. Now, Jordan, if I understand correctly, you won't be in Lisbon. You're, you're, you're not going to be at Jenkins world, right? I will not, but I actually have a quick question, not to sidetracked. Is it any of that going to be live streamed? The hack fest, definitely not. I don't know if they plan to live stream any portions of the conference in the past. They've live streamed the keynote addresses, but I, I don't know. I don't know. I haven't seen anything saying that Lisbon will be live streamed. I know that San Francisco, a portion of it was. Okay. Cool. Oh, like, had you heard anything with regard to that? Yes. Likely there will be no broadcast. Okay. Even for key notes, you find this time correctly. So I'm not sure. Do we have advocacy? I appreciate meeting today. I think that everybody is on the cube console. Likely not. Yeah. I thought that Tracy had canceled the advocacy. Meeting today. Okay. Yeah. Okay. I did get a chance to speak with the adopt team yesterday. And I did find out that around hopefully next week, or in the next two weeks, there should be the enabling of Debian and Alpine and UBI based images. So those are in the work behind the scenes right now. And the plan from what I understand right now is they're going to push to the unofficial repo first and then verify everything is. Up to stuff and then move forward going to the official repos. Excellent. Okay. So that. And those will be. So even Alpine. Okay. That's very interesting. Yep. So the adoption is going to try Alpine again. And from what I hear that it's going okay. So hopefully with some development with that. So in this case, we talk about both Java 8 and Java 11, right? Because I don't think it right provide images for 11. I'm not sure where it landed. I'm not sure exactly which one they're going to package Alpine with. I can ask and get back to you guys on that. Right now we don't provide Alpine for Java 11. Personally, I'm happy to keep doing so. But if there is interest from someone to have this image, we could try it. Yeah, I thought that the open JDK project had explicitly rejected Alpine for Java 11. Hadn't they all like that there? Yes, they did. And yeah, I've seen that adopt open JDK had some experiments with it. I haven't seen the final state. Yeah, and I agree with Oleg that there's no issue for the Jenkins project as far as I can tell if Alpine does not support Java 11. We already have Alpine support for Java 8. But the open JDK team's decision to not support Java 11 lobbies that we don't have, it's not as big an issue. And I haven't heard much press from other consumers looking for Java 11 based open JDK or Java 11 Alpine support. All right, well that is great news, Jordan. Anything else you wanted to report there? So I just had a quick question for Alex and if he was able to get through his tests and if he needed any help, I can direct him to the proper channeling to get direct internal help. And that's on nano server? Correct. I saw that you were able to submit your bug issue and that's also been merged, Alex. And then there was another one blanking on it right now. There was another one you had opened up about running the test cases. It was just a, I just wanted to kind of run additional testing to make sure there weren't other issues that needed to be fixed before a full like nano server image could be like, you know, approved, I can say. I did try and get some of the stuff going. I needed to change my image to include things like M-Sys to compile and things like that. So I haven't had a chance to do that yet. Okay. If you need any help with that, I can give you an email and a Slack channel available. I can just put it in the SIG chat. Okay, cool. And then I also wanted to just say that Adoption is really excited to keep moving forward with you guys. They're really interested in coming more involved with the open source community. Great. So now, and the nano server, do I have it in the correct place? That is related to open J9. Not to just adopt open JDK hotspot. Or is it, is it both J9 and hotspot? I think there, hotspot is working fine for nano server. I submitted a PR to adopt open JDK. So I'm happy to build nano server images. My guess is they will only be in the unofficial list for a period of time. But at least it's, it's rolling that I had issues with the open J9. So that's why it was not submitted as part of that PR. And so this work is to be able to support open J9 images as well for nano server. I see. Thank you. Okay. So the image source is not a blocker because we have Jenkins for evaluation repository. So we can create images based on unofficial images and just deploy our experimental version if needed. Yeah. When you were working on multiple platform support, there was a lot of patches for deployment scripts. So it shouldn't be a big deal to implement it now. Thank you. Thanks very much. Jordan, anything else you wanted to report there? Lastly, with that 890 pull request with the optimizations with the open JDK J9 image. I believe it was. We did locate that individual who made PR request and unfortunately today his manager was not able to join, but there is drive behind that pull request and there is active work going on with that behind the scenes. Great. Okay. So that's and PR 890 is that's the one that there was a predecessor to it that was similar that we were going to ignore for now and 890 is the one that is active. Is that correct? I believe so. Yes. Great. That's very good. Thanks very, very much, Jordan. Anything else? That's all for today. All right. Well, thank you. Thank you. Next topic then Windows installer. Okay. Yeah, so Alex, would you like to drive it? Sure. So. There is a branch that has been created in the packaging repository. And so only changed the target of my PR that which is great. So that's kind of tracked in the right place. He also made some suggestions to the pull request and I have incorporated those changes. So I think it's, it would be good to get some more eyes on it. I don't know if there's anybody else who has experience with Wix Windows installers. But just getting some eyes on it would be good. I was able to build the installer maybe two months ago and test it. So it worked fine on my machine that point. And since it's an experimental branch, I think we could just go ahead and integrate it because the story blocks could release automation. So why we need this experimental branch? There are two pull requests. One is from Alex to consider Windows packaging. But we cannot merge it right away because it would impact the key keys automation for releases because he relies on scripts. So there was agreement to just integrate everything at once. So the new core of this automation would include the new Windows packages. And that's why we need the story and integration branch is a good approach for us because we can just lend this change and if needed to build something on the top. Personally, I'm plus one for merging this branch. I already approved that. If somebody else takes a look, we can just integrate this stuff. And then include new releases in the experimental release folder, which is already deployed by Olivia. So it sounds like we definitely need it. I'm plus one for it. I have not evaluated it. Is it crucial that I've got Windows available to me? I could run the evaluation, but time is pretty crunched right now. Yes. One thing that, yeah, since we have this automation and works, maybe we could just kill two heads and test the beats produced by release automation flow. Right. Yeah, basically whatever we merge now it won't impact the production. It won't impact the Jenkins weekly or LCS releases. So that we can be quite relaxed about what we integrate. Okay. So, so if there are changes, it's not going to, not going to damage the production Windows installer package that Kosaka creates. Excellent. Then I'm plus one to merge it. Yeah. I can put a comment on it that giving that, making that plus one public. Mm-hmm. Alex, are you fine with that? Yeah, sounds great to me. Yeah, thanks a lot for all your work there. Yeah, the whole project, but yeah. Yes, Alex, you have been absolutely heroic on the Windows installer. Thank you very much. Anything else Alex or Oleg? Nothing from me. No, not for me. All right. Thank you. So the plugin installation manager. Has released. 1.0. And I think and 1.0.1. And that's, that's great. I have not yet put it into use in my, my case. So there's still work to do there. Next topic Mac OS native installer. Oh, like. So yeah, I'll probably just screen shape. If you don't mind Mark. Oh, please, that'd be great. Let's see. I do. I need, I probably need to stop sharing first there. I've stopped sharing. You should be able to take the share now. Okay. Do you see my screen? Yes. Okay. So yeah, Mac OS native installers. Okay. So we go to the repository, which we already discussed a few times today, packaging. There is a pull request for. Yeah. For new built environment. And one of the things there is that. Yeah. There is quite long to do this there. But the OX, OXX packaging is not marked. And yeah, there is a reason for that. In order to get more OX package, you need Mac OS somewhere. And this is a problem for our new environment because it's based inside Kubernetes. Yeah. Thanks to Alex. We have a window support there, but we don't have Mac OS support. And basically, there is no expectation of having it anytime soon. And so obviously we could have used the external. Service, for example, Mac stadium or whatever to build these images. But the question was whether it really makes sense because firstly, we have a blue images. So yeah, just, for example, a blue formula for Jenkins. So anybody who uses Mac OS will like to use blue. It doesn't include. Graphically user interface for installer. So for Mac OS, we have similar installer as for Windows. But yeah, the problem that we cannot really build it. And the idea was that, what if we duplicate it? And instead of that, just say that homebrew is our new package, which we would recommend. So there is a thread in the developer. My name is about that. And we built the consensus. And yesterday, we had the Jenkins governance meeting where you basically approved the duplication of this package. And right now there are two patches pending. So one is documentation patch, which basically it works. How everything is documented. Because now if you go to Jenkins, your download. So here you can click Mac OS. And basically you get the installer right. So like that. But it's not what we want. And then I just reworked this page. So now it will include. I have screenshots. So I don't need to run anything. So we will have a new page, which basically promotes homebrew as a default package. And the different installers will be still there, but they will be in Jenkins mirrors. So everybody will be able to take the releases. And these packages will be considered as third party. So we don't make in them and said Jenkins project, but they will, they will be still available. So yeah. That's the plan. And there is also a blog post, which we'll announce to that. One of the interesting thing there that you need to define some different duplication plan. And this plan is. Why to complicated there? Because we cannot say when we release a core automation. So what I did here, I said that, okay, starting from the next weekly and next LTS, we can see that the packages is deprecated. Then once a new core release automation follow is done, basically we will stop shipping packages. Yeah. So one problem there is that it has security implications because if you stop shipping packages, it also means we stop shipping security releases. For those who use packages. So there is some immigration guidelines. Well, I wasn't able to test them because I don't have more costs anymore. But yeah, there are some pointers to people who want to migrate. So yeah, this is a summary of the story. The use of pending and I hope that you will be able to enter them soon. And I guess the documentation is also similar to what we need to do for Windows packages because once we, so now we have a chocolate tip packaging. So maybe we could do something like that. So we could reference installers we ship. Obviously we don't deprecate them. So they would be on top. But we also can reference homebrew on their landing page and in our installation guidelines. Sorry, not homebrew or chocolate. So that we just close the loop there and have better documentation. Okay. So, so just to be doubly sure. So that means that Kosike continues generating macOS packages with the current process, but we will formally stop generating them when we transition to the new core release automation. Exactly. Okay. Thank you. Because yeah, it just doesn't work. So we can just go back to the first time and that. Well, we could do it later. If there is a huge demand, but historically nobody really maintains this installer. We didn't have infrastructure. It takes time and everybody uses it. So what's the point. So, and there isn't substantial gain by telling Kosike. He could stop generating the macOS proxy package sooner, but we just do it all as part of the core release automation transition. That's my plan. Okay. If macOS packages are being generated, no need to change anything. And when they stop being generated, okay, we can do that. One open question is actually with LTS because yeah, we're tempted to say that. So the tentative new baseline is 2.204. This is a discussion in the developer mailing list now, but it's not confirmed. But yeah, usually our processor that we don't duplicate anything between LTS releases and he may, might happen that 2.204.1 is released with macOS package. And the next release is released without macOS package and to make it more fun. It may be also security release. So yeah, this is the gap which concerns me a lot. But yeah, I think that in this case, we will just coordinate with Kiki to make sure that the two or the three releases also released with macOS. So there's a potential that even when we bring the new core release automation online that Kosike could run the old release engine for a piece, for a piece if we need that piece. Yes. So how currently releases work. So if you go to packaging, there we have master branch basically master branch is used for weekly, but for stable releases, there are other branches. So you can see them there. So it means that yeah, there is a branch for the currently release and for the next, there will be another one. And what it means that even if we integrate this experimental branches into the weekly baseline, it won't be a problem for us. And yeah, for weekly, if something stops working, okay, we can live with it. So it's a security release, but for tears, everything will be stable. Excellent. Very good. Thank you. Thank you. Thank you. So yeah, just heads up, but again, the reviews will be appreciated. And I hope to really integrate this one. Great. And I hope to get a review. Things are a little crunched this morning, but by end of my day today, I fully hope to get a review and approve on the, on the dock side at least of the macOS native installer deprecation. Thank you. Excellent. Anything else hold on macOS native installer. Nothing for me. Okay. All right. Last topic is on broadening platform support for Docker images. Actually, this is one Jordan. Is there anything that you needed to report there? I have not had any further con conversations with these potential folks. And so for instance, Oregon state university. With their available images. And we hadn't done any further discussion on the Docker image auto build. So I'm just going to leave this topic and let it wait for our next platform SIG meeting, which will be in about a month. Yeah, we can let that wait. One thing I do want to mention though, Travis has officially released the S 390 architecture for their auto beta automated pipelines. I believe it's going to be in beta. I have a link for that. I can give you after this as well. Okay. So that's a, that's a yes now. We have good. Okay. So we'll have S 390 in beta also. Thanks. Good to know. Okay. Any, any other topics we need to discuss today and the platform SIG next meeting. Oh, right. Yeah. Thanks very much for reminding next meeting. So our next meeting that would be scheduled would be for. Two weeks from today, which we are at. Okay. So I'm just going to bring up my calendar. It would be the 5th of December. No way. I will be unavailable that day. So then the next logical one would be the 19th of December. Right before the holiday break. Is that okay with everybody? If we make our next meeting the 19th of December, that's a, that's a workable day for me at least. 50 50 for me. Would it be better? Oh, like, would it be better? Yeah. So on my case, I'm traveling from December 15th to 18th. And on 20th, we have a corporate event. So basically the 19th is the best possible option. But yeah, I still cannot commit that I will be able to participate. Great. Okay. So there's a risk. Jordan, Alex, any, any preference from you is December 19. Okay. For our next meeting. Yeah, that works for me. Yeah, I think that worked for me. Okay, great. All right, then we will put it for the 19th. That means the, the December 5, 2019 meeting is canceled. And I'll send a note to that to the dev list. And to the Gitter channel. And the other topics we need to discuss today. I had a question about Jenkins core. I mean, the new LCS release. But yeah, I'm not sure how interesting to use it to others. So we can take it offline or just do it on the record, whatever works for you. I would love to do it on the record. If since we're all here, what was your, what was your topic? Oh, like, Basically, we had the LCS release yesterday. And we still don't have change logs. And we still don't have a great guidelines. So I wanted to just to sync up with you. What we do there. Yeah, so my, I apologize. Last night I had to go to bed before I could get to the change log in the LTS. So my mark to create. Change log and upgrade guidelines today. So you will probably see them for review as you start your working day tomorrow. That given that I'm, I'm going to be most of the day today in these webinars. And it won't be till the afternoon, my time that I start on them. So delayed. Until. Reviews until Friday morning. Do we want to consider switching to wealth? Yeah. Yeah. So, yeah. Well, whatever works in this case. Yeah. So I'd say uncomfortable, nearly unacceptable to have a don't worry about it. LTS without docs and without release notes or without an upgrade guide. So there shouldn't be anything which really worth some great guidelines. But yeah, we still need to push the things out. Okay. So usually we prepare stuff focus in advance because folks. Yes. So this candidate gets shipped with two week at once. And it means that this time you can already create change looks and. Because unless something goes really bad, it's what you're going to get. Right. And, and this, the mistake I made here with two dot 190 dot three is relatively low harm. If we make the, if I make the same mistake for the next LTS, that's significant because it will be two dot something, a number much larger than 190 either 198 or 204. And therefore there will be far bigger changes that need to be in the. Upgrade guide. Yeah, so we definitely know that there will be a great guide interest and some incompatibility to that. Right. Okay. Excellent. So now in terms of calendar, the next LTS. RC is due out within the next week, or is it a few weeks December eight. Okay. You say December 18. Yes. Okay. Good. All right. So just for information. Yeah. So Martin already knows the story, but we are basically in the pick your poison state. And because there was a fix for consistency model on the version 2.1, sorry, 2.199. And there were just regressions discovered in J. Kask after this fix. So, yeah, now we check, take it at 2.2 of four, this sun pieces on J. Kask site. Or we take a version before 2.199, but at the same time, there are legitimate bugs and configuration. See if they, though, these bugs have been in the Jenkins code for a long time. And I assume that the discussion on the Jenkins mailing on the developers mailing list continues. Yeah. It's pretty hot there. Okay. Great. Yeah. So I'm not sure where you'll find the finish with it. But there is no changes between the versions, which really impact. From seek. I mean, there is none of our stories, which I included. But yeah. So the pick your poison state is not, not specific to platform that's the challenge, right? But it is rather that there is, is lots of challenge between the two, two places either. Yeah. Okay. Well, assuming that J. Kask plugin will eventually lent in this special interest group. And even without that, J. Kask has been used quite widely, for example, in Docker. I think that it's important for sick members to know about it. Right. And the, there was a patch proposed to J. Kask. I think you mentioned that. That short-term attempts to work around it. Yeah. So. But the idea of this patch is that let's just put a sleep. In a proper place and keep our fingers crossed that the sleep duration is not. Right. Yeah. That's not a terribly comfortable, comfortable patch. Yeah. Just wait, wait long enough. I've done that lots actually with Selenium style tests, but I don't like deploying those kinds of things to production and then relying on them. Just wait longer. Yeah. So I personally do not know what to do there. Yeah. I agree. Well, I would go to 1.98, but yeah. He made a point that it excludes a lot of the quite features. Right. Yeah. Anything else on the LTS information. I don't think so. Okay. Yeah. So one thing that in the next change log. an XLTS baseline, we all need to document the packaging changes. So for example, if you lend some Docker image on your platforms, it would be really great if we add them to the change log finally because we do not do it right now. I just introduced a GitHub releases for Docker packaging this summer, but I think that this major highlight should be in the main change log. And they're pretty much the same for duplications like MacOS. Good, I agree. That makes sense. And so you're saying that right now that the core Jenkins change log does not talk about the Docker image, right? Neither about Docker images, nor about packaging. So for example, when we lend change from Alex, it also won't be mentioned automatically because there is no pull request in Jenkins repositories, so we didn't actually track it. Great, that makes sense. So we put it in the change log and certainly it needs to be in the upgrade guide, right? Packaging changes. Well, packaging changes which really require actions for people who operate. Right. So for example, for Windows installer, yeah, the installer would behave a bit differently, but I guess they're compatible. So I mean that you can upgrade the historical Jenkins instance with the new installer. Oh, good, okay. So it won't be the one of the upgrade steps is completely remove your Jenkins installation, your Jenkins MSI and add a new one. Good, okay. Yeah, at least I suppose so. So it would be nice to double check it with Alex because it's a quite important thing. Okay, thanks. Yeah, I guess that's very, yeah, I'm not sure whether he's listening, but yeah, you can follow up later, fine. All right. Any other topics we need to put on for discussion today? We're all over time, so. We are, I think we're gonna go ahead and stop the sharing then. I will post a recording. Thanks very much to all of you. Jordan, Alex, thanks for being here. See you in four weeks. Thanks a bunch. Bye. All right, bye.