 Cool. One thing to mention about kind of our workflow for releases, we try to do LTS release line, so promoting and telling about one release amount. And at the very end there's three of us doing the LTS release as my own to the second challenge. So that's one kind of quarter which is actually going to take that amount. And I'm not sure Miles is going to continue to do that, so obviously getting more people on it can share out a bit more. And the current release schedule kind of varies between one per week and one at a time. It may take a little bit less. In the LTS release sometimes, because that's a larger team, but you will get conflict so depending on what conflict you're in, it could take up a bit more time. So it's kind of easier with releases. With LTS release, we are at the moment trying to reduce the number of conflicts by backporting the zembrometer care, which means that we, as soon as the zembrometer lands, we have a look at it and then we open the backward part with the zembrometer patch. So we do a specific patch to backport everything and it's not a breaking change from the zembrometer and to then land the original care with the zembrometer on top. And there's going to be an argument for while reviewing some of the major PRs to ask people to make it as narrow as possible and to check if it changes the throat. It doesn't matter anymore pretty much. As long as we do that, that's fine. Because I would actually say it's more of a case where we care less about that than before because we do backport everything. We release team backwards. Whoever did the care or released team, whoever, in this case, we just have to make sure it's backport. Some PRs, we can directly say it doesn't make any sense because the breaking change itself, everything it does is breaking. But most PRs can normally do like, okay, you switch like this part and then the rest of the code still stays the same. But and the breaking change is gone. And then you have less conflicts. Because in the beginning, when we have a new release line in the major, it's easy going. It's like everything lands like cool. The more releases you do, the more conflicts you hit. One of the parts to always prevent is letting PRs out of order. PRs out of order make the worst conflict. This is a mathematically, the 10 to X difference between 10 to X and 12 to X, that's probably coming up with two and a half thousand minutes. But we know just manually order it and go for it and put it in. But when we hit backport, when we hit commit conflicts, we have a label saying back to request it, then we all get out sick, which causes more conflicts. And we're kind of in a state where we just can't catch up. So now we're at the 10 to X where we can only put in really changes we either ask for or I'm cleaning, or we request it this way back or because the branches diverged last much. So what we're trying to do is make that easier then forwards, but we will have that problem in the 10 to X. Yeah. In the forever. There's no way that we can do that. That's over. But what we can do is ongoing that from the 12 to 10 to X, it will become easier. Also for the maintenance part and long-term support. So I just have to zoom up in and I'm not actually doing anything because nobody else is on there. That's what I'm just smiling at the chat and stuff like that. It's a problem we're supposed to be doing. Okay. So the first bit, we came onto new releases. Here's about a couple of volunteers. I actually take an action to shadow in things we had. So I found that really useful. Previously, people have started by filming current releases with all the people that asked a bit of my idea. It's the same process for each lighting platform. I'm not sure how to use that. Yeah, I don't think we have enough context. Sorry. Oh yeah, that's exactly it though. I don't have enough context to choose either. So if you think one is better. I would say most of the time, out of my perspective. I think we should talk about the most meetings where we discussed that this is still requiring them off. I think it's still a formal requirement that we decided that we would not have that. That we should remove that formal requirement. Oh yes, to do a preparatory proper process. And also that you probably didn't know what what is going on. Like there's an imperative that's as bad as the release of the release of the release of the date. And like, at the moment, the whole process is super, super manual. You can break everything all the time and you always make mistakes when you just forget what's happened. It's a lot of stuff. It's like it's 23 or something. It's 19 or 23. Yeah, it's everything's manual. Everything is you can forget something and the luck. The question, is there a checklist for that? Okay, that's how you got that. We've discussed it last week to approach that. That's that's one of the things that I'd like to do eventually is like, once I've done this a bit, then I can get to that. So yeah. I was thinking that I might be a way to get my mind to extend that to charity things, of course. So what, uh, is this your meeting? I think you're aware of the release group. I feel like I should have to be here at half, not me, you know? Is that why you're in the doorway? So we haven't even discussed this. So we should definitely make sure that you become like you're in a queue very automatically and then with the PR, that's a common staging problem and run the testing automatically. And assuming that there's a conflict, the pipeline has to stop you and say, this is conflict. And then they do not let any other PR in the meanwhile until conflict is resolved. Why? Because one of the worst things is backcourting is always in the other portion of the project. And if you do that, you create worse conflicts. Because sometimes, let's say that the following up here actually lands immediately, but it changed something internally. But now the test's all there. So you actually have to then an bisexual problem. And, um, like for one current release, I think a bisexual age commits. And if there's only, if there's only one correct order in which the commits can land, that helps with automation on this list. We do have, like, so we build a tool to detect which commits should land in which order, but especially since we now land in the center, your meter of PR is well in between, this is even less conflicting. Because now we have, like, it almost always the current order. Well, and don't you have it literally a increasing or an incrementing log of the PR numbers? Like, can't you just go with that? Or no, no, no, not at all. We land in PRs completely all the time. Yeah. PR number orders when it was open, but like some PRs land right away, others take weeks, 20 years. Right. But even if, like, anyone that takes weeks, wouldn't the ones in the future still be? No. No. Okay. I could. You're absolutely right. Sorry. And number is aside when you want it open. Yeah. So I had to, um, because I'm learning multiple PRs in a row. And while doing that, um, everything was so green for all of them. Like, all the guys passed. So you land in PR. Now you land in second PR. Well, it turns out first PR comes in second. Well, still lands clean, but the test is open. So, uh, Rafael has joined the Zoom chat and I'm just going to let, uh, let him know that there's, it's a pretty small group here. There's only two people from the release working group. That's Beth Griggs and Ruben Bridgewater. And then it's me, Tierney Walid, and me, you know, great. I got it. All right. So, uh, you let's share it again. Huh? Yeah. Got it. All right. Take away that. Okay. Or Ruben, or something. Um, related to your faculty major 12 changes, the topic that's smart quite a few times is, should we change the concept of what flows through the PR? So when someone opens a major PR, if we merged into Mark, open up and pop up, but the actual PR, we're going to get closed when the appropriate faculty's been merged. So I think against that, there's some partially, and some people on the virtual PR as an act, and they're going to close it and partially we close them. And, uh, yes, it is a bit, so, so it's a real concept of the release group. Because what we are working on is closed PRs, not with open one. We don't land anything. We just don't speak in that way. All closed. Okay. Yeah. We use labels to deal with that. Okay. Yes. No, you show. You show us an example. Also, just to clarify, when you say when you land in your career, by major, you're defining a large career. Yeah, December major, yeah. Raphael says he's having a little trouble hearing it in here, but I'm just a little bit trouble. Is this? Oh, yeah, this, this looks like it would, might be the microphone. Okay. So we have a filter by label here. We have backport repressive. So, and this is actually, and this means there is a conflict in some way in this career that the release cannot resolve on its own immediately because sometimes there are like tiny conflicts that I just resolved right away while lending the commits. Like if it's obvious, you know, and then, then you can do it and you run the test and everything passed. But if it's not that way and it's conflicting, and then you go into the PR and market as backport requested with the current release that you're preparing. Yeah. And then the manual backport has to be open for it. Backported to 11 or backported to version X that means it was requested and it is now backported, which is a bit redundant because we don't normally use it. Then we have don't land on version, which means sometimes we say explicitly, this should only be backported until a specific version, which could be important for, let's say with the age change, because some change might be December minor, but it could be like a slowdown on old versions, but the performance improvement on new versions. So depending on the V8 version as an example. Can we just man plus that? Like, can we zoom in bigger? Thank you. I don't know if that helps. All right. Do you see it? Yeah. Yeah, definitely. Okay. I think it responded. That's cool. I hope you see it. Yeah. So that's the don't land on. That's always during the landing process already. Normally, sometimes someone might come also later on, but that's super rare. Not only we just don't have it. And then we have the version, whatever version it is, we use it for open backport PRs. Yes. This is nodding a long knowing lick, which means that when you manually backport something, this label would be attached to it. Okay. You'll always say often people put in title as well, like brackets. Yes. In the title, it's always good to do that. And like almost no collaborator knows how to use these labels. It kind of sounds like y'all are really overworked and improving process is a nice to have, including automation. Yeah. So yeah, because for example, one very typical mistake that people do is that they add a, let's say they want to have a PR backported on a specific release line, then they actively add the backport requested label. Now that does exactly the opposite of what they actually want. Right. Yeah. I think we need to clarify what all our labels mean and somewhere in the docs. I think renaming the label would be good. Yeah. Yeah. Yeah. I mean both. Yeah. Yeah. Because while those we've discovered on this product, naming labels is hard. And I submit to you the author ready label. But go ahead. Exactly. It was like multiple things. We're all like, oh my God, what a discussion about it. And it's still not really, not a lot of people use it. But anyway, yeah, sorry. I didn't mean to get us off topic. Also, if you ever are stuck for things to do, I'm not sure how well we've socialized it. You can search PRs and hit backport requested to 10.x. And you can actually, you could try picking up one of those PRs. And then you basically open a diff and try to apply that diff to the 10.x release line. Sometimes it's as simple as a few variables if that's the names changed. You just need to reflect that change back on your branch. It typically the owner of the original PR will do the backport for it because they're the most familiar, but not everyone keeps up with it. And there's some that have been around for years. So would backporting of forgotten, unloved PR be a good first or second contribution for someone? Because my feeling has always been backports tend to require following a bunch more instructions about what branch to open it against. And then, you know, how to resolve the conflict that results in the backport being requested in the first place. But I also kind of wonder if having a bunch of instructions to follow is actually good for a first time person that like that's much better than just being left to their own devices. I think at some point, I may have spoken to Michael and say it might actually be a good thing to run a little session on a house of backports because you've got the code there. So you don't necessarily need to write your own feature. You just need to know how to apply that exact diff or that code change to the old release line, which can be quite a nice, intuitive way of starting to contribute to call. Okay. I have someone who, okay, yes. I tend to disagree on that because it's actually often challenging to know, like especially let's say 10 and 12, when you backport some PRs or like you want to backport even to eight, because this is so immense that and then you have like often the worst backport PRs are C++ code. So people have to be very knowledgeable about the actual code that was changed and not only about the change itself, but also about former implementation. And about whatever changes causing a conflict, probably as well. And then to know how to resolve that conflict and not only the conflict, because sometimes change might land, but then a code change in another place, you change the logic that you have to identify why it is breaking, you have to run it. So this is actually quite challenging, especially for the request ones. Yeah. For the ones that have been sitting there. Because I was going to say like, there are certainly backports where it's just like, oh, it's just a white space diff that needs to be sorted out. You know, there are easy ones. But those, but those tend to just get done. Exactly, exactly. That's like, I could normally do that while learning. Yeah. Sometimes when you're preparing a release though, you're like 200 commits in, and you can see like a load of white space changes or lots of written conflicts, I'll just add the backported label on because I think I cannot stay up another half now just to get this one commit landed when I've got a hundred more. But then you've got the issue where I'm now waiting for that commit to be backported. Or the order goes like it is a compromise. I'm either sacrificing the order in which it lands or I can't land any more commits. And when we're only doing one minor per quarter for an LTS release line, we can't wait for all of them to be resolved. Absolutely, absolutely. I guess it is going to become easier when we have the automation process. And then is this thing worked on? No. Okay. Do you have work? Do you have time? I mean, I can probably do either automation or, I mean, this is something I've wanted to do for a while. I can do automation or releases. So the problem, for example, was like, we discussed this multiple times, but time is so limited for all these clients. So what you will also work with is a lot of decision. Yeah. And like Michael, Michael is doing a lot of work there and Richard Lau and me. And the thing is with all the releases, you have to run Sitchim often. Yeah. And then there is a lot of flakes in there and a lot of PRs that you have to update. You have to resolve the conflicts, why this module is breaking. Then you have to update the list. You have to update the code. Oh, it's a lot. Triage and Sitchim is a very big time save. Yeah. So it's just very, very time consuming. And we need it to release more versions. So the time was invested into releasing new versions instead of optimizing. Yeah. But if you mess something up during the release, you know, right away, or there has been time that you released and they passed, and then you realize that you made a mistake and then you have to release an inversion. Okay. And does that happen very often? So I just did recently, but it was like, I mean, that's the exception, not the rule, but it certainly happens. There is really something on a Tuesday and then we realized, oh my gosh, we should not release something on Friday. So with the day, it turns out this has a very strong, there are very different opinions about the days when to release something and when not. So, but the main problem about this, this all comes down to when the individual person has passed. Yeah. Right. And this could be an old person on the weekend. And I think that should override all the concerns about, oh, we don't want to do a release on Friday. Especially counter-intuitively, perhaps that's especially true with security releases, where we want to get them out when we can get them out. Because we don't surprise people with them. We post a week in advance, we're going to do a security release on or around such and such a day at such and such a time. Sorry if it's on a Friday and you think they shouldn't be done on Friday. Doesn't matter. We're telling you in advance, and then of course there's SAM proposal to actually have a regular cadence for security releases, which I think is a very, very good idea, because the release team can set a side time, and the users can set a side time, and it'll be patch Tuesday. Everybody will know when it's coming, a long, long, long way in advance. So I guess the question I have is I would love to do both things. Both of what? I have automation and releases. So you're putting the cart way in front of the horse, you're trying to figure out which one to do. Right. Well, no, I'm just saying I only have time for one. Yeah. Well, at the moment, I would say like no matter what, you should probably try to induce some releases to even know what problems you're facing. Yeah, exactly. Yeah. And then figure out what you're going to do, like keep them releases or automate or... Cool. But yeah, you're not going to be able to automate without actually doing the work probably. Yeah. It's going to be my... Yeah. Cool. Yes. That's been our issue. We've got people like a few of us together who can do the releases and then some people drop off, move on for whatever reason. And then we're left with all the releases to do. And then as I mentioned, it took a good six to nine months, the Miles mentor and me to be able to do a release for my own, so... And like I also like just recently I was angry about myself where I did a small mistake in the notable changes. It was not noticed early on. And well, the notable changes is missing a name from that. Well, because I changed release notes in a meanwhile and I copied something wrong and it was like, yeah. It's just a lot of manual work. Yeah. And because of that, mistakes happen. I guess I'm the only one who noticed, but... So as far as process goes, you said that Miles has been onboarding you. And so the way you envisioned helping newer people get familiar with it, did you mean that they would piggyback on the existing process or you were going to start your own meetings too? I'd probably start my own and then try and expand about that or any of us could... What I've started doing is scheduling time at work when I'm allocated to work on backporting and things. And I think Shelley does something similar on Miles does and then we went through a phase just opening the Zoom whenever we were doing it. And people would hop in and just shadow what we're doing and talk through. People have time. Right, right. Cool, cool. I have a question. Probably I missed some earlier position, but what is the motivation behind backporting everything in the upper branches to the LTS branches? Ideally, we should be looking at only the stable ones or the ones which are actually required by users. Yeah, I think it's conflicts going forward. So if you backport everything, you're less likely to hear conflicts when something thick comes in. Yeah, but then it works against the LTS philosophy. For example, in the bleeding edge, we see something breaks. Quite often we see that. And we are actually inverting all those breakages into the LTS. We do have time frames. So you're only supposed to pull things back once it's been in current flight X number of weeks. And there are some. It's kind of like a release of case by case basis. There are some PRs and I think Miles and myself definitely looked at. And we've seen people have posted issues on it. And we haven't pulled that back. So it's not like a black and white absolutely everything gets pulled back. There is some cherry picking of which minor should go in. It's not clear. I think our documentation states that on the best case, we will pull back what we can. Yeah, so is it possible to classify the features which are landing in the master in a way that these changes and the family of changes what is happening over there is potentially backward porting candidate. So that you can actually start back. Yeah, I think I'd prefer it that way myself if it was when you open this as an order, you're like, should this apply to 10 and 8? And if you added labels at that point, it would be easier for us because we would know what needs to come back. That way you're reducing your work a lot and start back porting as soon as possible so that you don't face the problem of complexity. So normally it's done in the other way around. So normally we say by default every commit would be backwarded. But if anyone expresses concerns about it during the PR or even later, they add the don't land on version release side to it where it should not land. And that also automatically implicitly implies that all versions below that one should also not be taken into account. Normally we add every explicitly, but it is actually from the release team done implicitly for all versions below. And so we have something like that. We also have a base for LTS, which means at the moment as you just said that there is at least I think two weeks time frame. I think two or three. Two or three, yeah. And the PR has to be released already on a different redesign on the current one and before it may be backwarded at all to LTS ones. And I don't know, but was there any, did you hear any complaints or concerns? Because so far I'm not been aware that this has been a problem. Yeah, there wasn't any complaint as such, but the way I look at it is LTS by default should not change at all. It should focus only on field reported issues and the issue is resolved in the latest branches, latest releases to put back for it because it's already fixed and has some amount of test cases that surround that and proven to be stable. Then you graduate into the LTS. Yeah, I was kind of speaking to Sam Roberts about similar saying why do we put minus in LTS release lines for like nine to 10 months? Because if you didn't, people would have an incentive to move up to the latest LTS. Do you use the new features? There would be less work for us because we'd only have to backport fixes or I think we would still backport features if people raised cases for them. But those features would obviously conflict a lot more. Yeah, I don't have the numbers, but I see issues coming from the field which are from the LTS. So if you actually look at in a systematic manner, we can see that some of these issues are coming from backported issues, backported PRs. Yeah. For example, something which works on 10.15, bricks in 10.15, 16. So definitely come from backport. Yeah, yeah, yeah. It could happen. Yeah. Yeah, it's something. This could happen with the fix as well. It could happen with the fix as well, but yeah, that's a classical regression. But whereas in this case, it was a feature which was not intended to touch this area of code at all. And it sounds like a regression to me. Yeah, it's all regression, but you are not addressing the user's pain point as such. You're not addressing a reported issue. You're entering a feature, you're fixing some of this problem, but eventually causing some other use case to break. We don't seem to be... I think it would be a pretty dramatic change to say we'd kind of be saying it goes straight into maintenance after current. And therefore we'll only get like fixes to regression as bug fixes. Maybe I could maybe have some exception saying that some miners could land, but we'd have far less. Yeah. And I guess it's an interesting point definitely and we could discuss it, but then I guess it should be a bigger round because this sounds like a huge change, like about every release line we've had so far. Yeah, the whole active would... I would not even want to decide this as a release group, but more like all collaborators. Sure, yeah. But it's a clear trade-off between how much time you are spending on development effort. I mean, you tend to do back port as much as possible to reduce the development effort, but on the other side, the side effect is going to be consumers. The one I mentioned, Sam had when I mentioned this earlier, was that you want people to be able to try out new features on older release lines before they upgrade. That can be a good idea, yeah. But if we don't back port some of the miners like any additional features, they wouldn't have the opportunity to test something out while they're on no date. That's going to be more disruptive than my proposal, I guess, because right now everything happens in the master branch. I can't even... Do you have an opinion on this? I mean, I've... The problem... No, I mean, I find the argument that not, you know, that by keeping the LTS branches as up to as in sync as possible with master, it greatly simplifies, you know, the maintenance of those branches in that, you know, new things land much more easily. And there aren't big, impossible C++ heavy back ports that need to happen. On the other hand, I also understand the expectation, you know, the default expectation of an end users when they have a branch that's marked LTS. This is not a node thing. This is, you know, what LTS is to most people is something that will, you know, that will be supported for a long time. And I mean, it's really... Although, okay, so be support for a long time and undergo minimal changes and certainly no breaking changes, although we're not talking about making breaking changes to LTS. But then on the other hand, I do think that the main thing for most people is that it's supported for a long time, that they're not going to have to endure breaking changes, but not necessarily that there won't be, you know, a lot of updates. So I don't know. So, I mean, and ultimately this, the release working group's decision, but I do also completely appreciate Ruben's comment that like, this is not the type of decision I want just the release group to make. We could open an issue. I agree with the point so far that what I've been working with the companies, when we're using LTS, we want to support not the new features. We will look into that. That would be supported for a long time. That's what we care about. Not the release case. Not the release case. Like, it's okay if there's a lot of little documentation updates and a lot of... You pick a release and that's what happens. And that's what you stick with for a while. And then you eventually upgrade it. But not what my experience when it comes to requests on the notebook repository. Actually, like most requests are not about the back takes, but about can you... Hey, can I have this feature? Yeah. So, I mean, the whole... So, go ahead. On that, is it from the same people? Or is it from a specific... No, no. So, what I'm saying is, is it from different people asking for individual features? Or is it one group asking for a new feature over and over and over? It's different persons. Yeah. So, that doesn't exclude what I'm asserting. Because if someone wants one feature, they might get that and then they'll stick on that version. And then they won't upgrade. So, if it was the same group coming multiple times, I would say, okay, that's an indicator that they want to consistently update. But if it's like people randomly asking for this feature or that feature, that's not necessarily a signal that they're like all trying to update fast. And like, I mean, with my experience of both Microsoft and NodeSource, people stick, they pick a version and that's where they stay. And until they... That's also a problem. So, there's another thing that we haven't actually touched upon here, which is that there's not all... There's actually like, we're talking about like current and then LTS, but there's actually two flavors of LTS, right? For the first year, LTS is active. And then there's LTS maintenance and... We are working on the naming. That's enough. Sure. Sure. I mean, naming is naming though. The point is that whatever they're named, you could make the case that the... Yeah, once it's in maintenance, once it's in its final year, we're not going to bother... Like, we're going to release only when there's a security fix or a critical bug. Otherwise, we're not touching it. In fact, that might already be what we did. That is pretty much our statement. Yeah. And so that would be consistent with what you're suggesting, but then the LTS active line could be something that is... I mean, it's right there in the name, right? Active. It's not... You know, it's getting more than just critical fixes and security. Maybe security, I think, we even do for the versions which are not in the LTS. We only do it for the currently... Security, this is only current and LTS. Okay. So it's at most four branches because there's a brief window where there's three LTS... Where there's two maintenance LTS branches and one active LTS branch. But usually it's... Yeah, usually it's three branches. Could a suggestion be that we extend the maintenance phase to be longer and reduce the active phase? Yes, maybe. I mean, what we could do is to have a survey about it because I... Well, I mean, so there's a lot of inputs here, right? Like, what do end users and customers expect? There's what do the companies who support a lot of end users and customers, the IBMs, the near forms, the node sources, the Microsofts, what do they expect? And then there's what can we do that doesn't make the volunteer releasers completely miserable? Yeah. Like, you know, like... And these things might be at odds. So I think a survey is a good idea, but I also think that, like, you know, kind of like actually actively thinking about what if what if what we need and what our customers need are very different things? How do we resolve that? Because I suspect it's more likely that that's the case than that it's not the case. Well... Because that's the other thing, like... So what I really hear is that it's pretty much the two extremes. I know you're more in the middle with your suggestion, but for me, I think the main thing that we could do as releasing work group is either we keep it at the moment that we backport everything after a specific time and we try to actually get everything in there, like really everything. We were just talking about it earlier. We started to backporting Zembra majors in a Zembra patch way. So we add a specific commit on top of the Zembra major that makes a Zembra patch to remove the breaking changes. And on the other hand, we could extend the maintenance phase of the LTS release, which is pretty much exactly that, that we only backport some fixes, like only patch commits and security releases. And then it would mean, okay, we have to do less releases overall, which was less commits, so that's also okay. But I don't know. So here's the patch. I think I know what I would recommend if I were on the release working group, which I'm not. But I would say do what you were planning on doing, like backport everything, not backport, but land everything in the same order, minus the breaking change parts. But actively seek feedback from people. People might think they will be bothered by something that when it actually happens, they're not bothered. And vice versa. They might think they want something that when they actually get it, it causes them problems. It might not be a bad idea to pursue something, message it, let people know it's happening, and sort of just see what happens. Because it's not like you can't decide to just stop doing that. You can absolutely, at any point, just decide to stop doing it. Stopping from doing something though, once it's already announced to people, seems like there would be inertia and there would be pushback. People don't like, whatever I'm trying to get at is, people don't like something being taken away. But the people who you're taking away from this case is the release working group, like, you know, I mean. With release, I thought I've not heard really any complaints. We should probably consult in one conversation. Go ahead, go, keep talking. The only thing I've really heard is the only thing that I've seen it vacuum for is security. Like, people don't have signals for when a security release happens. It's very not straightforward. Like, a bunch of individuals tweet it and no JS might retweet it. But like, that's the only thing. So that comes down to a different part because our communication with changes is not great. Like, last week I've been on a conference in Russia and we had a... I got to go downstairs for five o'clock, but I don't know what would be good or bad and a couple of things. And it all came down to documentation and knowledge about changes. Like, people did not know that something was in a specific release. They did not know that the feature was actually in no JS at all. And really like us to maintain a list of what's in. I think it exists somewhere, but it's not something we use. Yeah, so like, maintain what's in each release. So we do have the change mark, but it's something not consumable for people. And I guess that comes a little bit in that direction. But it's not really about release group, in this case. Because a release group is mainly focusing on doing the release. But this is mainly about bringing knowledge and information to the user. And this is something we really have to do. Makes sense, yeah. I agree. I understand. Chris has come. That's not fun, I guess.