 Hi everyone welcome to Drupal long-term support if you'd like to run out to another talk really quick If you're in the wrong room go now I'm Jeff sheltering From tag1 consulting. This is Jeremy Andrews We initially wrote this talk with Nat catch pole Unfortunately, he couldn't be here at the conference But I've been communicating with him and Fixing all my mistakes in the slides thanks to him. So any mistakes are mine and Jeremy's is mostly mine Anyway, I'm Jeff sheltering. I'm a senior infrastructure engineer at tag1 consulting I've been involved with Drupal since my previous job at the OSU open source lab So I don't know what that was 10 12 years ago gone into Drupal I'm also a member of the centOS QA team. So I'm pretty involved with Linux and systems administration and Just LTS support it for software in general And I'll let Jeremy give a quick introduction as well Hi, I got started with Drupal in 2001 I had a blog called kernel trap that was running on PHP nuke and it crashed a lot Every time I got linked from slash dot and Dries reached out and said hey We're writing this really cool new CMS that has something that no one else has it's called a page cache it's not done, but it's gonna be really great and Then he sent me access to drop.org which predated Drupal and Drupal dot org and Followed up with another email that said by the way, that's root access And please don't delete anybody or change anything just you know look around and see what you think And that's been a great and consistent experience for me in Drupal Which I've really liked is that everybody's yeah, always great That was version 3 something I've been actively writing core code since Drupal 4 and I Like to be involved in this long-term support. I like to make sure that no one's left behind I'm curious. Does anyone here have a Drupal 5 website? Besides you Drupal 6 Okay, Drupal 7 Drupal 8 Anyone on Drupal 9? There was a day where someone would have been on Drupal 9. All right and Nat who's not here is the Drupal 8 one of the branch maintainers And it's unfortunate. He's not here because he has all the answers for this We sure talked ourselves up So I quickly wanted to kind of cover some terminology we're going to use in this talk Specifically LTS Meaning long-term support That's kind of a widely used term in the Linux world Kind of more so now as we're thinking about doing such for Drupal The the exact definition of LTS for Drupal is actually up in the air still kind of the The Agreed-upon definition is something like as minimal possible changes and fixing security issues What that actually may look like in practice? We don't know yet and it may be different for Drupal 7 and Drupal 8 and Definitely those will be different from what happened with Drupal 6 which we'll talk about shortly And the next term is EOL or end-of-life and in the in Drupal context What that's referring to is a release that's no longer supported by the community So anything Drupal 6 and previous are EOL releases And I think I'll let Jeremy cover kind of Yeah, the history of how we got to where we are with Drupal 6 LTS specifically So Drupal 6 was the first Drupal release that had a significant number of Drupal websites left on it when It decided it was gone end-of-life And what that meant was that people weren't happy about that because there were over a hundred thousand websites still using it and We didn't want to just abandon them And so it was an it was the first instance where the Drupal security team supported More than two releases because there was eight there was seven and then there was also six There was a three month window where the community supported for security back patches and during that time they reached out and Got several vendors involved So yeah, we're one of the three vendors. There was Acquia my drop wizard and then tag one We have a product called tag one quo, which is awesome. And if you have Drupal 6 you need to check it out the The key takeaway though with this is it's called Drupal 6 long-term support Drupal 6 LTS Which is confusing because LTS has a new meaning for Drupal 7 and Drupal 8 So I think of it as extended long-term support and it's paid long-term support The way that it works is that if a paying client of one of these three companies has a module and There is a security release for Drupal 7 or Drupal 8. We backport it. We release it publicly And we make sure that our clients get it So what that means is that if no paying client? Uses a module that you're using on Drupal 6 It's not going to get backported as part of this program and That's you know, it's definitely a different a different system, but it's nice because the patches are out there and Specifically if you go to that URL you can find every patch that has been released for a Drupal 6 long-term support there Our product our product is tag 1 quo I won't go much into the advertising except to say that if you're on Drupal 6 and you don't have security patches We're giving away. We have a promotion right now where it's three months free and that means you know Any modules you have will backport them for you There is manual effort involved but sign up now because it's the best time to do it Get your site up to date and It also supports Drupal 7 and Drupal 8 But yeah, that's tag 1 quo Okay, so I'll talk a bit about what's happened in a year and a half Since February of last year when Drupal 6 was end of life At that point there were roughly 115 or 120,000 Drupal 6 sites reporting to Drupal org And that's gone down over the last year and a half The latest report from this month shows 65,000 sites reporting so roughly Cut in half the number of reporting Drupal 6 sites accept them and to cut you out for one second we wrote a crawler to go out and Try to figure out who actually is on Drupal 6 and Drupal 7 and Drupal 8 and While that that is true for sites reporting back There's almost twice that many that aren't reporting back. So it's over a hundred thousand Drupal 6 sites still out there We also did a campaign to contact some of them and say hey We have the service that you can use and it was interesting like a fairly significant percentage of people said wait what my Drupal 6 sites still up I didn't even know that And I guess interestingly that that's only covering publicly facing publicly accessible sites So who knows how many internal sites there may be on Drupal 6 So in that time period since it went EOL and has been supported by these three vendors There's been 25 patches released One of those was for core and a whopping five have been for views Which is nothing bad against views, but it just so happens it's had a lot of security fixes in the last year and a half And just I think this is kind of self-explanatory, but the what are the some of the benefits of long-term support? Basically, it's giving sites a chance to Last longer on their current code without having to jump into an upgrade that they don't have developers for don't have money for And it also is just a way to have a stable code base. That's only receiving Security fixes, so you don't want to take a chance on whatever new features. It's going to be a much more stable code base To add to that also though from like our perspective with quo in addition to this This is kind of community-focused. We also You know We don't we're not trying to pressure anyone to upgrade from Drupal 6 to 7 or 8 or whatever We're going to be around as long as people are using Drupal 6. There's still 10,000 Drupal 5 websites out there too, which we're not supporting but they exist so we're Yeah, anyone on Drupal 6 you're not being abandoned as long as it makes sense to use it which for some people it still does And so Drupal 6 LTS has been pretty well defined What's not well-defined yet is what's going to happen for Drupal 7 and Drupal 8 and beyond So we want to kind of take a look at the current status of issues and discussion on Drupal.org and Hopefully get some discussion here in the room about it as well Looking at Drupal 7 specifically There's currently just under a million sites reporting Drupal 7 back to Drupal.org So it's pretty clear that that whenever it is that Drupal 7 goes end of life It's going to be a lot more sites still on Drupal 7 than we're on Drupal 6 when at EOL So it's something to consider this is going to have a much further reaching impact in the Drupal 6 end of life And Like I mentioned it's still up in the air. There's no date set yet for Drupal 7 LTS or end of life And LTS in this context means something slightly different than Drupal 6 LTS Which is supported by the three vendors when I'm talking about Drupal 7 LTS What I mean is a long-term supported community supported version of Drupal 7 And the plan is to whatever the last release of Drupal 7 is would be an LTS release Where for some undefined period of time that's going to be continued to be supported by The Drupal community and Drupal security team Until it goes end of life So there's kind of an open question also when that end of life does happen Does it make sense to do a similar handoff like was done with Drupal 6 where the security team kind of Stop supporting Drupal 6 and handed it off to the vendors or is there some other better option or or no option I'm not sure. Yeah, and the question is in part in large part dictated by The capabilities the the time capabilities of the security team, you know, it's it is voluntary and It is going to make sense at some point to stop supporting Drupal 7 But that's also going to depend on just at what point The people involved in Drupal 7 don't want to support anymore. There's lots of discussions out there There's proposals out there. It does not look like it's happening anytime soon You know, it's going to be at least a year and a half out I would say is the earliest where it would and this is where LTS would start and LTS will then go on again for You know, don't quote me on any of this but a year year and a half probably as well So there's there's there's many years of usable Drupal 7 lifetime left Drupal 7 is also a bit of a special case as we'll see But things are improving in Drupal 8 and beyond That should simplify upgrades and hopefully make this more of a solved problem Unless of the pain point like it is right now for anyone on Drupal 7 wondering when they need to make a move Do you want to cover this one as well Jeremy? This is basically a summary if if you want to look at Drupal.org these three issues I pulled out Or where most of the activity is happening around Drupal 7 and Drupal 8 LTS and EOL discussion and the current summary of this You want me to jump in or you sure go for it is a The commonly accepted proposal that Both Dries and the core commander seam on board with is start Drupal 7 have an LTS release only once the Drupal 7 the Drupal 8 migration is is fully supported and Migration is fully supported is Maybe a kind of vague definition. I think we all heard Dries's keynote. He said there's still 12 blockers Critical block 12 critical blockers. So, you know in my opinion, maybe that means when those 12 blockers are done Someone else may have a better opinion of what that actually means But that's kind of what they're aiming for currently is is have an LTS release once the migrates complete once D7 and D8 migrate is ready And then have a D7 end of life right around the time of the Drupal 9 LTS release and Drupal 8 is even more complicated If you thought 7 was bad Drupal 8 Theoretically will have an LTS release sometime Around the Drupal 9.0.0 release Whether that's going to happen before or after is it's up in the air We're going to get to some more detail on that in a minute actually And the EO up the end of life for Drupal 8 is also undecided Will it happen after the 10.0 release? Potentially extend till a 10.0 whatever LTS release of Drupal 10 or even Depending on how the Drupal 8 to 9 and 10 migrations work out Maybe Drupal 8 doesn't need to stick around as long Maybe it could be end of life even sooner if there's a super simple upgrade path to 9 for anyone using Drupal 8 I'm actually curious to understand so part of the confusion that we're We're talking about is that we hope things are going to be a lot better And not so it's not confusing because we just don't know what we're going to do It's confusing because if this works as we hope it does Fewer people get left behind people get stuck on old releases is anyone so we're up to eight four in about a month I think is when that comes out is anyone in on 8.0 still or 8.1 or 8.2 So everyone 8.2 and then 8.3 anyone else that's on 8. So that's that's a great sign that people are succeeding in upgrading and following these releases because I Don't know how closely you're following Drupal 8 development But some more significant changes are being made during the 8x development process and And it's working people are upgrading There's do we talk about backwards compatibility later? Yes, okay, and then I'll wait to jump there, but Well, we'll get there. Let's cover this and then you can get there. What's that? So this is basically this is an example image and I didn't create this I pulled it from the release cycle overview URL you can see there and this is Kind of to give you an idea of what it might look like you can you're you're already going to notice that Drupal 7 LTS has not happened yet like has happened on this timeline And also I think what Something a little bit confusing about this chart is The mention of security fixes only There's kind of some Confusion about if there's a difference between an LTS release and then it's locked down even more and there's security fixes only I Think actually the LTS release would be more or less security fixes only and it would only be some very Critical bugs fixed if those are found So this is going to loop loop back more to what Jeremy was talking about with the So there's a lot of interesting discussion out there Nat in particular is is leading the charge on this and and the good news is that this is being talked about not because it's happening Tomorrow it's being talked about because Drupal 6 was the first time we had any LTS and We know it's going to happen again with Drupal 7 so we're we're planning ahead and so with Drupal 8 The goal is that We don't do Drupal 9 until we literally need to do Drupal 9 for some reason What Drupal 9 will mean is is you know anything that's been deprecated is gone But in Drupal 8 an example that gives is you know well Let's say we want to completely rewrite the forum module and completely replace the back-end how it works with entities It's possible to do this in Drupal 8 and to do it as a minor update And and the way that would work is the old forums module would it no one's rewriting forum right now This is just an example But in any case The old version of the forum module would still be there you'd probably remove the UI So you wouldn't be using it from the user interface But then the new version would go in there and they would they would be simultaneously both supported through different namespaces Any code that you have that depends on the old forum module would continue to work because all those API calls everything is there but then Anybody who's you know building new websites would use the new system and then for a series of minor updates It would be there. So we're talking 6 12 18 months That during the 8x process you would have both of these APIs there and any contrib modules would have a chance To to do this migration there's lots of lots of warning and it's not only a chance to do it But it makes sense to do it because you know all these Drupal 8 websites. It's it's alive. It's not something in some future release It's part of what everybody's using The people on 8x here, you know, they're they're keeping up to date and they would keep up to date So the goal is that as a contrib module maintainer you've got plenty of time to bake the switch over The old forum code would only be released then we removed from the code base once 9x goes out So there's there hasn't been an example yet of anything significantly changing like this. It's all talk But there also no one's come up with an example of how that's not going to work how it's going to break So that's definitely where things are leaning right now In these issues Drees does weigh in and several other core Committers and I mean this the the the verbiage up there is something like, you know, this is the plan But we're open to change it at any point So if if we have a better idea or if it doesn't work for some I some reason then we'll change the plan And the one other thing I wanted to call out from this slide is There's actually a recent issue open this 2909 la la la proposing What if we could extend the support for Drupal 8 minor releases? So for example Support 8.3 for maybe a few months after 8 4 comes out So there's not that immediate like hey 8 4 is out go upgrade your sites today. Have fun Kind of give people a buffer to to be able to upgrade safely and do some more testing There's actually no discussion on this ticket yet. So I'd love if everyone hops on there, but Basically at this point, it's just a proposal In my talking with Nat about that issue specifically um He agrees that actually that would likely be very trivial Very trivial amount of work for the core committers and security team Because almost any patch would be able to be directly re-rolled back in the the previous 8.x release So I think that makes a lot of sense in my mind and and that that makes a lot of sense as well because you know If you look at the differences between Drupal 6 and Drupal 7 and Drupal 8 Even there it's not that much work most of the time to backport patches from Drupal 8 or Drupal 7 to Drupal 6 When it affects people there for for long-term support. So certainly between the eight-point releases, it's going to be a lot easier and Do you cover everything you wanted to about the this kind of The only the only other piece of that is that When the other piece of this is Drupal 8 is wonderful. It's it's a good system, but it took too long You know, there were mistakes made One of the great things about Drupal is people talk about that and they're public about it and you know It's all part of the community So these tickets go through and that in particular details some of the the things that could have been done better the problems that we want to solve So so part of that is The goal will be When we release 9 You know for starters 9 9x development will start in parallel So that when it actually gets rolled It's ready to be it's ready to be used and it's going to be you know The 900 release is not going to be a drastically Changed system from the 8 the 8 dot last whatever releases say it's 8.10 for example so Going from the last 8x release to the the first 9x release should be as simple as each of these Simple 8x updates you've been doing and and if this works, you know, this is this is a game changer for Drupal That means that people will be able to stay up to date We'll be able to really you know over slowly get rid of You know our technical debt But continue to make changes In the discussion threads, you know, there's some concerns about you know The internet moves really really fast and if we're always trying to be backwards compatible is eventually Drupal going to get left behind It's an open discussion It's possible that you know 9 will be a nice smooth upgrade and then 10 will be Another major change Again, there's just an awful lot of unknown because that's right now 8x is working very well And we actually intentionally left this talk pretty short because we're hoping to answer some questions or have some discussion about Whether it's d6 d7 d8 and beyond So fantastic and there's a mic please come on up and use the mic if you have any questions or comments Hi Actually, I have two Questions the first When there is a security update security advisory for a Drupal 7 8 Contrib model How the three windows or three companies work together or separately to make it possible to be patched on Drupal 6 Okay, first So yeah, great question. I was actually supposed to tell you that without being asked, but thank you for asking Um We have members on the Drupal security team and so when the patches We know before they're released as everyone on the security team does that there's a security issue But it's not anything that gets talked about publicly until the patches are out So Everybody in in the the companies that are doing this is is involved in that Somebody does a backport If only one of us has a client that has this module then obviously that person is going to do the backport Otherwise it just it just depends but in any case It gets reviewed on this through the security team So anybody in the Drupal security team even can look at the Drupal 6 patches and sometimes do It's a it's a wonderful team. People are really cooperative But yes, we always try our strategy is not to push the patch out as quickly as we can But to take it, you know on a case by case basis, it's super critical It's got to get out there quickly Otherwise, you know, we'll we'll take up the 24 hours to do heavy testing and make sure that by the time It gets out to people that it solves the problem The with Drupal 6 The patch will cannot be released until the Drupal 7 or 8 patches are out there But technically ours can go out, you know a minute later and sometimes it does depending on, you know How much testing is required for the changes And again, regardless of who wrote the patches, they're all on the project on the d6 lts and all accessible to everybody freely That's really cool. Um for a second A few months ago it happened. Um Kind of a lot of months ago when there was for 8.3 a core sec update And it got also Released for 8.2 like I don't know over half a year ago. No less than half a year ago. It doesn't matter What do you think if something similar will happen when 8.4 in the next week or two weeks later? We'll get out And an update will happen a security update for 8.4 Will it be kind of automatically released with uh 8.3? Or what is the strategy? Do you know anything about it? Officially, officially there's going to be one supported branch 8.4 But as you saw with that example, uh, it's also going to be sanely done And if it's an easy back port and a critical back port It would be very surprising for it not to get back ported. Um, it's Yeah, there's a limited amount of time, but we're not going to make silly choices also and say well, we're not supporting that It's not a corporate decision. It's very much a community and support the community decision, which is Drupal Yeah, thank you Drupal versions itself, but backward compatibility what you mentioned I have recently have one issue on my control module like The drupal supports php 0.5 0.3. I don't know Can you make the changes? So it's also related to this long term support Will the it It exists some discussion about that that drupal maybe move faster with minimum requirements like php 5.6 is slower supported or I don't know how it's how we look on this Well, it's problem for control models I don't know in several points to support php 0.3 0.4 0.5 0.6 7 7 1 7 2 and we can go on and on So I think it's related to this topic. Uh, how drupal can move faster in terms not only the code But the code and infrastructure so So each each I'm not sure understood the question actually So each version of drupal has a minimum requirement for php And are you suggesting then for in the 8x branches that we keep raising the minimum php? Yes So basically for drupal 7 lts I think it doesn't make sense that somebody even if he runs. I don't know drupal 7 in 2022 that he had php 5.3 on the servers So what I can say is that we have a drupal 6 clients that have upgraded to a more modern version than is supported by drupal 6 Which works quite well in most cases and it involves testing So it is possible to do that But I think jeff is better suited to answer this in the sense of what you're really looking at is Working together with you know the linux distributions that are packaging up php and hosting companies which Yes If community invests more time in Latest software and minimum requirements If I have company if I have my websites on some shared hosting and some small site builder and so on and I cannot I don't mean minimum requirements. I will go to a company which has I don't know php 7 or something like that I think it's much simpler Then it's look then then it looks from now like I think Speaking personally, I I like having the lowest possible minimum requirements I'm also the maintainer of the memcash module and I did some did some recent testing to compare You know php 5 some different versions of 5 and php 7 And I mean it was a 2x speed up just by switching to php 7 So on one hand absolutely php 7 you should be using it if you can But if you can't There's no reason to leave it behind I cannot think that we drop php 5 now Okay, for example in php 5 triple 7 now supports php 0.3 0.4 0.5 and 0.6 I think php 5.6 is like The minimum requirement and any modern hosting has Probably seven but so with lte in various linux. I mean what is Red Hat's probably still way back there. Yeah, I mean that's the issue with languages like php on the long-term supported linux, uh, so Most a lot of people are running red hat enterprise 6 for example and that was released with uh php 5 3 So red hat is still minimally back porting security fixes to php 5 3 theoretically Uh, I haven't actually seen any recently though. I don't watch that closely Um, there's workarounds obviously if you can control the server So, uh red hat has a thing called scl I forget what actually that stands for but it's a way to slot in different versions of of languages like php Or you could actually get like apache 2 4 onto red hat enterprise 6 where it shipped with 2 2 and still supports 2 2 um So yeah, I mean there's there's ways around it and there's no great answer to it really because Everyone has different needs Some people want to be on 7 some people want to be on 5 3 for the rest of their lives for some reason just they're afraid of change. I don't know Or they have custom code. That's just too difficult to to upgrade um, like jeremy said, we've had a number of old Drupal 6 sites That started out on probably Whatever version of php 5 or even 4 uh, go to 5 3 go to 5 6 and we're seeing some using php 7 With very minimal changes from my perspective And nearly all the changes are in custom code There's a bit of some contrived module cleanup, but nothing major that we've seen I mean, I guess it'll come down to when there's a php feature that You know is profoundly better for Drupal to use and to make that a minimum requirement Actually, can you talk into this the microphone? Thank you Trying to a little bit help you There is a sniff Sniffer provided sniff That can check your code. Is it kind of ready for php 7? You just execute it as a php CS with the right sniff And it tells you what are the changes that you have to making your code even though Drupal core 7 and 6 are totally fine Mostly the contribs are good But the custom there can be some tricks that you have to change and you To php 7 Thank you. Yeah Any other questions Having in mind the introduction of Drupal 7 long-term support as you have explained And that the transition from 8 to 9 should be almost seamless, let's say We hope In in an enterprise context with a lot of like 100 of Drupal 7 websites and a lot of customizations Do you think It should be better to invest already in a Drupal 8 migration or wait for Drupal 9 Even you know, there have been a few core security updates on Drupal 8 And you know for an enterprise might not be easy to To upgrade hundreds of websites with a zero-day vulnerability something like that What is your opinion? We get that question a lot Through tag 1 when people ask whether or not they should update I would say that Drupal 8 is mostly ready for you now and and that as an enterprise you can probably afford To do it and if you can't afford to do it It is you know, if you're sticking with Drupal for the long term this model that Drupal 8 is moving towards is working And so we expect it to be around for a long time It comes down to how much you can invest as well, though I mean are the contribe modules you need there if not Can you help get them there if not then the answer is no, it's not right for you If you can the community can absolutely use that and there's still lots of modules that are being imported Yeah, from from another perspective, I mean Drupal 7 is not going away anytime soon from the community perspective And you know the tool that we built if it does go away from the community, we're going to keep supporting it as well So it will always to some degree to be supported It's just a question of you know, what's more cost effective for you and you know, what features do you need and It's definitely time to start looking though if you haven't already Drupal 8 feels like a really big change and and then the more you use it the more you realize it's You know, it's Drupal. It's still Drupal and you know in good and bad ways There's silence. So I guess we're done. I've been Asked to remind you all you've probably heard this 50 times There's sprints on Fridays or Friday Let's do them every Friday. Yes, uh, sprints on Friday. Uh, come on down have fun and Give us a good or bad survey response if you enjoyed the talk or not and thank you all for coming Oh, thank you Questions Yes, I know I'm sorry Right, you're correct. We're not the two of us are not. Yeah, but I work with them and we talk to them daily Okay, of course Okay Which one was this? Okay Still So you're referring to Drupal 6 specifically and you're looking to backport patches there or you're looking to So so I do know that there has been at one or two patches that was contributed by the community I don't know if you were involved in that and but unfortunately the reality is that We don't put our stamp of approval on it if it's not if there's not a client using it because Once we've done that then then we're technically supporting it So the only way to do that is to invest the time of testing Spin up a website with whichever modules and and test to make sure nothing breaks So yeah, so that so it's automatic Yeah, I mean it's automatic in the sense that it raises a flag that says somebody has this module There was a security release, you know and now to to turn that flag off We have to look and see does this security issue in seven or eight Effect the six one and then we manually do that and yes or no if it does we backport it If yeah, again, it's it's being used by a client Does that answer your question or no, I'm not sure From Yeah, so you so ultimately that's that is the rub in that He's working on getting his access It should always be No We don't like it doesn't bother me seriously they really Right so so publicly the only way you're going to learn about it is But paying attention, uh, there's no subscription. Well, actually. Yeah as far as I understand it Maybe my drop wizards you can use their module and learn about it without a pain on that shore With ours Sorry to know that it's there, right? It's not Yes, but it would be manual and you would have to like with our service you would only be notified of patches that affect you Yeah, it's not automatic in that sense unless unless you've signed up There's no way to like say hey There's the security issue coming if you want to help back for it because we don't talk about it until it's already public And once it's public we've 99 of the time we've already written the patch We might still be testing it and and sometimes it's really helpful to to see how the dupal 7 or dupal 8 patch goes to Because there's enough similarities that sometimes we've had We'd like views I think was one that there was a back ported patch that had have another back ported patch because of Not understanding some fallout and it affected those releases too So we try not to Not in triple 6 though Test the Drupal's testing framework was just simple test this Drupal 7. Yeah, so Not in Drupal 6. No, we are not Yes, it's very manual Manual and and then sometimes even like working with clients to say, okay, here's the patch Here's the things that we are concerned about absolutely and and people are more than happy to be involved in that And while we sell it as it's an expert service, you know, we do all that testing absolutely will flag if we think it may or may not be a problem Mote and they most of them are not And then occasionally the ones that you think aren't can be I mean It's little things like the letter t instead of the letter t s or something Yeah, like, oh, yeah, or sometimes there's core bugs that aren't exposed until we back port security pitch fix Which is like, oh, wow, that's Unfortunate But you know, it's it's still interesting even though it's Drupal 6 and So I don't know if I've understood your question. You're trying to get on the Drupal other security team, correct? Okay Okay, and are you yeah, there's a process Are you close You're passionate about it. That's good Fantastic. And does Michael know this It's kind of my method. Okay. Oh cool. Well, that's a that's the perfect mentor to have actually He's great. And if if he knows that you're interested Yeah Nice Nice, that's cool. Thanks guys. So did you want anything with that in particular or you just were hoping to meet him and that's all Yeah, cool. Thank you. Well, good luck too. Yeah You then you're wrong because there's no one that knows it could it couldn't That doesn't mean anything though, I mean, I'm sorry, but I mean Drupal.org has comments It may have been in the whole I mean, I feel like lately All the all the references have been around Other release timelines and no dates are set for those really maybe I'd be curious to know who wrote that