 Welcome everybody. Thank you for being here Once more just because of the signage issues I want to make sure that you're in the correct session the what's next for Drupal auto update session if you were looking for the tailwind session That is next door. They're both 3.2, but there's a and b But otherwise it looks like we are good to go so we're going to jump in here shortly This is a panel discussion type session. We are going to present a little bit about The initiative riff on some things you may have heard in the keynotes and in some other places But we're also really hoping to get your questions and to be able to answer any concerns feedback Clarifications that we can have from you. So hopefully that means we didn't make too many slides and we have lots of time for For going through that Brief introductions. You've probably seen me all over the place a few times already, but I'm Tim Lennon I'm Hestanet on Drupal.org. I'm the CTO of the Drupal Association So together with a small and mighty engineering team We maintain the tools on Drupal.org and in this particular instance because automatic updates relies on the update Information served by Drupal.org, you know We're key partners in the initiative along with the core contributors that work on the Drupal side and some other Components that are Drupal agnostic. They're part of the kind of the wider PHP space So we'll talk through some of those, but that's myself Neil why don't you go ahead? So yeah, I'm Neil Drum. I work for the Drupal Association on the engineering team and have been working on some of the server side components of automatic updates I'm Wim. I work at Aquia's Drupal acceleration team and I was involved for a solid six months or so working on the Drupal module side of things But I'm really just channeling Ted and Adam Honig who weren't able to be here today so Representing the module side of things They're not dead. They just couldn't come to France Very sad. Hi. My name is Jess. I'm xdm on Drupal.org I'm one of the release managers for Drupal core and also one of the handful of people who Originally wasn't involved in the very first proposal of this initiative, which is Going on seven years ago now that we've been we've been trying to get it off the ground So we're close to the finish line now, which is very exciting I haven't been involved in the development in the past couple of years because I was busy with this thing called Drupal 10 And then this thing called Drupal 9 before that also laid off twice in the past year but It's obviously a very important initiative for us because we're concerned about the stability Security of core and the stability of the upgrade path which auto updates is a big solution for Cool so again, we'll set we'll do some Spend some time setting the stage and setting the context for this conversation before we take your questions But do you know jot them down as we go? You know the place we want to start I think is talk about the overview of why we need the auto update system in the first place And I guess it sounds obvious. We would love fights to be updated automatically But what's kind of involved in creating what we need so? One of the biggest issues is security As the Drupal.org infrastructure team we get some Statistics people reporting back what version of Drupal they're using right which means we know how many sites are still reporting back a Version before a major security release right and we know how many are out there that didn't patch something important And we want to really make sure that we can increase the security posture of Drupal sites to be secured by default But at the same time Code updating itself is kind of a terrifying thought So we want to have an automatic update system that ensures it doesn't become a vector for distributing You know men in the middle attacks and malware that turns all these Drupal sites somehow into Bitcoin miners Right, that's not not the place. We want to be either and so in order to do this We need to evaluate best practices from other systems We don't want to come up with an automatic update security model from nothing because there's a lot of software that already does this And if we can we want to think about systems that could work for the wider PHP ecosystem and not just Drupal So Drupal can perhaps prototype this auto update concept But we talked early on with folks at typo 3 at Joomla at WordPress And they and they all had interest in some form of this for their own projects And we said well Let's make components that are hopefully generic or could be extended to secure more PHP And then lastly, this is foundational work that goes along with the project browser and other things Right if we're talking about securely installing an update that's not too dissimilar from securely installing a new module So we want to all of these things have to abstract away from manually managing composer on the command line in order to do these things And so we can leverage it not only for this sort of security use case But hopefully for making it easier for folks to install modules a lot of foundational work So we'll talk a little bit about how we made some of these decisions So I'll go through one more slide here and then we'll talk about the other components. I'll hand it to some of my Co-speakers, but first is what was kind of the basic sort of cryptographic or specification or Structure that we were going to use as the basic building block and we looked at a variety of things We looked at the open bsd projects project signify or signify. However, you want to pronounce it Variety of different things before settling on a cloud native computing foundation project called the update framework tough And the update framework is there is a go implementation. There's a rust implementation There's a python implementation And it's used in some pretty like enterprise level production contexts It is also used in Sort of securing the supply chain of delivery for over-the-air updates for some Autonomous driving vehicles and cars and things these days So it has some attention and some support And it's got some mathematically interesting features that are over my head, but that some folks that I trust Have faith in So Tough though is really as a project. It's not software itself. It is a specification It has reference implementations and it has a few community implementations But one of our first things is that we would have to build a php Implementation of this tough signing process And so What is this component as part of the larger auto update system, right? This is something that says Hey, I've requested an update of my Drupal site. Here's a core version I think that I should be getting this package from Drupal.org is that the package I actually got right? This is the the basic thing that we're trying to do So this breaks into two components, right the source the server that is actually serving these updates and the client So Neal at a very high level Would you just talk a little bit about the sort of server side components and then either whim or just depending on how much voice You have okay whim what we're trying to do with the client So, uh, yeah Drupal.org of course distributes of the Uh All of the updates for uh Drupal Contrib and core so We need to provide the actual signing so the client can uh Can check that Yeah, it's relatively straightforward But as you may or may not know right if you're using composer you're actually Your third party dependencies are probably pinging packages and getting things from github and elsewhere But all the Drupal components come from a Drupal.org owned and managed packages endpoint Packages dot Drupal.org and so this is why we're already the central management point of this and why we're at the right position To insert the signing into our infrastructure, but Um, when can you Comment on sort of the client side stuff and what we want to do with Drupal just the basic overview before we get to the details Um Right, okay, so I wasn't sure what's like we were on exactly sorry Um, yeah, so the automatic updates module. Um, it first does a composer install into a separate staging directory to make sure that Completely without without touching your production life site at all We're fetching the necessary files and we're validating that everything is in good order We're also doing things like making sure that there aren't For example database of this present that might be risky to install In order to do all of those things We're using composer stager to create a safe completely sandboxed install of all the dependencies And in order to make sure that the dependence we get are actually the ones we think they are Claimed to be we're using php tough to make sure that they weren't messed with well in transport and so It is thanks to php tough that we are able to be very confident about the things that the composer has fetched for us That they are actually the things that they claim to be So we'll speak in a little more detail about how we what what it what is involved in running The server implementation of tough. So, you know, you've been collaborating with one of our partners on this. I'll let you speak to it Yeah, so Tough it's a specification. It's not a implementation. So we Wanted an implementation to automate signing. So we worked with consensus enterprises to Build that and make it able to be automated. So our packaging then the packaging it can sign Sign everything So he called that rugged to go with tough And yeah, the stats report is That's rugged is functional. We're as we're going through the next steps. We're finding and fixing bugs. So it's We're making sure it works at scale We built a proof of concept deployment To get the client side had to start on having some actual data instead of speculating on what Tough signed releases would look like from throughput org But we built that pretty quickly and it's junk now It was pretty helpful in finding Some bugs and getting getting them started, but we didn't build it in a way that was worthwhile to save So when you turn we turned around to build a staging deployment that is pretty much production quality and so that's done and All of that was for mostly contrib Drupal core is actually hosted on Packages.org and the downloads come from github So we don't control that part But we'll have to build a mirror of that for Drupal core to Sign that as well To clarify a little bit why that is right The assumptions sort of built into composer or the source the sources when you say composer install A package name what it's checking first is the listings in packages So we're publishing core and the subtree splits to Github so that it's there by default in packages and then as soon as you download Drupal it adds the extra Package endpoint source of Drupal's own packages and that's where the rest of contrib comes in so Yep, and that's uh, that's as far as we are with the server side Yeah, yep, and then so on the client side of things I was involved with making with identifying these things And like getting them going but it's mostly tad and adam that have made these things happen so back in Pittsburgh We had a drush console commands Rather a drush command I should say But of course we are not adding any drush commands to Drupal core So it had to be converted to a symphony console commands that has happened now And the really cool thing about this is um Or the really crucial thing I should say is that it allows a different user meaning A different user than the web server to be executing the actual Logic so you can do it in a completely isolated safe way if you choose to do that if You're not on a shared hosting environment And you really want to control in complete detail how it does actually works. That's now possible And you would then need to do some additional setup like setting up a cron job to actually make it happen So symphony console commands set of drush commands The second thing is that now it's compatible with the automated cron module that Drupal core ships with by default And it's on by default if I remember correctly Um But the challenge with the automated cron module is that it kind of runs at the end of a random incoming request every once in a while But bgp has this thing called max execution time limit So it can run for only 30 seconds by default some environments maybe five minutes But that may not be enough to freshly fetch all those packages and so on And so what we did a rather wet tad and adam we're working on is Spinning up a separate bgp process at the end of an incoming request Which then is able to run for however long is necessary. And so that means that even On the very restricted hosting environments You're not going to run into execution time limits And that uses that symphony console command And then last We for core updates were at least initially restricting The automatic installing of updates To only those updates that do not also change the database schema because executing database Updates are applying update functions There is A higher degree of risk than just deploying code And we want to absolutely avoid any risks there. Um, so we had a very rough worked fine, but there were false positives Approved so we had a approach that was very rough but had false positive potential And that has now been made much stricter much more precise And it's actually using the built-in laxing stuff of bhp to accurately determine precisely if there is an update or not So that means that effectively more updates will be able to automatically get installed because there will be fewer false positives Yeah, I'd like to highlight something that wim said sort of Buried the lead a little bit in talking about to make sure this works in shared hosting environments to make sure this works in servers with Less resources right half of the value really of automatic updates is not for highly resourced teams that already have Deployment processes and update schema and they're a whole CI CD pipeline and all this stuff It's to be there to make Drupal Have a lower total cost of ownership and be easier to maintain and secure At mid and smaller scales as well. So those use cases are super important when making these technical decisions, right? We can't just say oh, we're not going to bother doing that because that's only a problem on shared hosts Because those are some of the people we're trying to protect. Yep. Thank you Mm-hmm Should I cover the tough client libraries? um Yeah, maybe talk about this briefly sure Regarding the database update limitation that is like that's mvp limitation that we don't do database updates We may later allow sites to opt in To running updates automatically that do database updates. It's just that Especially for the initial version. We're trying to make it as low risk as possible um, and and also regarding The shared hosting versus having your own ci. It's also It's also extensible so you can use our tools with your ci You can add a step to your ci that does like the tough validation and so forth Uses our composer stager or not depending on your needs Yeah, and uh We make sure that uh, unless it's absolutely necessary Security updates don't have database updates. So, uh Not having automated database updates will still allow automated security updates. Yep. So that is the really crucial thing Pretty much no security update in the past Recent history in our memories at least has not had a database update The worst thing that the worst thing that we did was flag node access for rebuild Okay, and that is not Eight years Right, okay, so Hasn't happened in a very long time But of course it means that we need to as a community while working on Drupal core But in the future long few long distance future and I'm working on Drupal contribute We all need to be better by thinking about the consequences of update hooks and we need to Make sure that they're really thoroughly tested because imagine that an update rolls out Everybody installs a little map be an old Drupal size go down because we got something wrong like that That's the reason why we're being very very careful So in order to make sure that we can safely Fetch those Updated dependencies and making sure that they haven't been tempered with along the way. We have these tough client libraries So php tough does the actual verification the composer integration is a separate library And these things are built in a way that are not at all Drupal specific They're not integrated into the module itself They're completely separate packages that can be used by other projects as well And they can be fetus independently of the Drupal module code and so Nothing in them is Related to Drupal in any way and it also means that we can review them in apparently security audits independently as well Um, and maybe you want to take tough testing Um, I'm actually I might skip through because I do want to give a sense of time for questions And it is taking time There's a I'll say briefly. There's a lot of things that we are doing in terms of Validating everything that's going to be needed for the like experimental release of of automatic updates So varieties of testing metadata Issues are as a file size too large, etc. Etc. Some of the examples you see here And we're continuing to work out some of those details There's some status for when this stuff is going to be in review and what's needed that we'll speak to briefly When why don't you take Well, which either one sure So the package manager merge requests against Drupal core is ready It's passing every core test It's being generated automatically from the contract module Fully automated and it's a new review. So if anybody's Interested in digging into that you're very welcome to The automatic updates merge requests is Pretty much testing passing all tests, but there is a regression deep in the crevices of Drupal 11 It's batch system that is causing some tests to fail, but it's passing on Drupal 10. We'll need to figure that out But it is ready for review These few tests will be figured out Yeah, and I think we might have skipped over that Automatic updates it's for Drupal cores two big components package manager and automatic updates package manager also will automate composer for Project browser. Yes. So that's the independent component that will underlie both auto updates and project browser and then automatic updates builds on top of that Both of which building on top of the generic php libraries that were created to do the things like tough validation Some steps that are not described here as like regular Drupal issue collaboration review The association is paying for security security audits Of all the non Drupal components right now that audit has already begun So that includes the rugged signing server the server side It includes the client libraries and we're having actually the same sort of firm and A group of folks who have audited the go implementation and the python implementation so that We'll learn from the things they did and that we have the benefit of the people who actually have experience with practical implementations of the security side of things So that's ongoing We're going to start moving into q&a And I think I will Kick off with the one that I think is probably top of mind, which is when are we going to get this When is this actually coming out? And so we've talked about this before This is a a 2080 rule situation So there's maybe a 20 chance that we could still get this into the 10.2 release Code freezes end of october And there's a like hit list of urgent things that we need to do that. We're really putting a lot of resources into However, we're doing a security audit for example We'll be doing framework manager and release manager review for example We do those to find things and those issues may take time to fix and we might miss that line So the 80 percent bet is in the is on the june release the 10 three release As being the most likely candidate for when this is in core Um, so just because i'm sure that's probably the the top most important Thought in folks minds Um, anything to add there before I open it for other sorts of questions Okay, so uh, there's a microphone in the center, which I hope is Hooked up we'll see and if you have questions feel free to come over there or raise a hand and I'll repeat a question Yeah, and we have one from the app already. Oh, yes So the question is written. Is this part of a core module or part of an update module? I think we'll clarify. Yeah So this is a new module in core But there are changes that are being made to the update module pieces that are being taken out that will be redundant um, and It's and like the entire parts of the interface will no longer be required um The whole thing where you like paste in the url Of a contrived project to download it to your code base will obviously no longer be necessary for example So there will be changes to the update module, but the update module as itself just as an interpreter of druple.org's Release information is will still be there But there's so that's there's actually two core modules That's the package manager that we talked about that handles the actual composer interactions And then there's the auto updates module which takes care of Validating that an update is is safe for your site that it meets all the requirements that have been configured And you know the cadence and when it's installed Types of releases you would install and for all that logic is is and the updates themselves are done by auto updates Um, I notice that people are drinking water empathetically I'm going to try to stop talking here But then in addition to those two modules in core And the update module which will be stripped down from what it currently is there's Three packages on github as well That that we are using But that typo 3 and jumlah will also each be using at least one of Any more on the app yet? Yes Hi Just want to say thank you for all of the work on this It is it is really great to see and it gives me a lot of confidence as a developer in kind of you know the implementation And I wouldn't at all be scared to enable this on my dad's website for instance. Um, I just wanted to Ask a little bit about kind of kuzia I know you just touched on the the user interface side and with Project browser being another big thing that's coming kind of in this interlink with us How how much kind of collaboration or thought is there on the the sort of how those user interfaces are going to connect with each other because presumably you'll want you know Auto updates to work independently from a ui perspective of project browser And also just to say that obviously the the usability group is here to help if you need any help with those things So yeah, yeah, I'll say a few things and when one of one of the basic things Uh that i'll say that maybe we should should cover earlier There are some previous recorded sessions that have some examples of like sort of demo ui Kind of examples from previous cons and things like that you can look at but also the other thing to say is right We're focusing on core to start Project browsers focus will be on contrib to start and so there's a little bit of a sequencing that's going on there Deliberately in terms of thinking about you know core point releases security releases first Then thinking about okay, what's the way you could do this for? Miners what's the way you could do this in contrib those will be future phases of the initiative to add more and more value over time but I think yeah, so The sequencing means that they're separate but the intent is also that we didn't know at the beginning When which thing would be ready? We didn't want to like make it a hard blocking thing Yeah, we didn't want to make sure that they're tied together. So package manager was blocking the two So both project browser was blocked on its and automatic updates was blocked on it So package manager is truly critical. It has almost no user interface except for I think a status report entry So you're not going to really notice its presence Project browser is going to have a very rich user interface. That's what you saw in the keynote session earlier as well Um But it's focused on finding contra modules and so for that reason It has a very different need and a very different user experience and the automatic updates module And the automatic updates module you kind of don't want to notice you kind of want to make sure that your site is up to dates I think and At the moment it's limited to just triple core because for contra we don't know if every maintainer is strictly adhering to Semantic versioning if they're We know that every maintainer is not adhering to sticks at mantic versioning or paying attention to what kinds of Breaking things they put in their updates. Yeah, it's not the optimistic somewhat pessimistic But totally true. So nobody wants to risk this not even optimists so I think that over time automatic updates will get a richer user experience in a sense that there will be more settings added To allow it to be more granular about what contra things you may want to Have installed under what circumstances, but now i'm really extrapolating none of us have talked about this. This is far future stuff So it it is also of note that Usability review is not a beta blocking step We did we kind of glossed over the fact that the the 10.3 date that we're targeting for june To have auto updates in core is for it to be in beta experimental stability So beta experimental stability means a module gets security coverage It gets bug fixes. It gets A bc guarantee An upgrade path all of that But it has not yet finalized its user interface Usability review design Such as it there is. I mean it's right now. It's very very basic old school for me That that would be happening more as we progress from beta to stable So after 10 3 we would begin to work on the user interface more And we would have the opportunity at that point because i'm sure I'm sure that project browser is going to be stable by then for sure as soon as package managers in Like the project browser will be in the next release. I think Um We can you know take at that point see where we are and Make make improvements and and those logical connections where necessary Yeah, there's a little bit of ui for the readiness checks as well, right? Yeah, so yeah, which is also kind of old school Yeah, so right now the the kinds of ui that you would see if you install this or if you install the contrived module version Which is like sort of a testable thing not something I would do in production probably But you could you could certainly play with it like your options are Choose to run an automatic update on like a button press an attended update basically Choose to say yeah, I'm going to opt into doing it on cron And check the readiness report which says, uh, do we have right permission to be able to stage the files and a few other little things? Right like it's enough space So making sure your sites in good condition to be uh, you know, if you've hacked files locally You shouldn't auto updates the sites not in a good place Yeah So but what you know an underlying thing that we said here, especially in the contrived module discussion Is I think once this is present in core and there's greater and greater demand to say Can I auto update to the next minor? Can I auto update my major top hundred contrived modules? Is probably we will need a community education campaign again about Semantic versioning about good hygiene in your release process and all these sorts of things But I think by showing the value of doing an updates in core we can kind of provide energy to that effort So we'll we'll do that when we're showing what it delivers That community education campaign also hopefully Will eventually become tied to metrics that are used in what's promoted in project browser So module maintainers who are good about semantic versioning who don't break Sites with their updates Who opt into security coverage all of those things That make a module safer to update to would also be Surfaced higher in the in the default sort of project browser Yeah More questions. We have a couple. Oh, we do in the eye. Yeah bottom first Okay, so one is is the symphony console command a replacement for doing composer updates No, it's a short version The symphony console command is is about being able to run this whole process Which is going to take minutes at the very least to Fetch the new Basically create a copy of your entire site and then run composer update there So composer update. Yeah, it's kind of it's using it under the hood, but it does a lot more than just that yeah And uh, should say all of this does use composer internally Or emphasize that so yeah So, you know the idea here being we're not suddenly breaking away from the architecture of a composer based management for these sites That all all these things like the heartbreak and the the heartburn that went into doing that in the transition to droop Elate is actually being preserved But it is trying to abstract away from the complexity of that when it comes to keeping your site up to date Or when you're installing modules with project browser. Yeah Next question is can auto updates fix like or handle composer patches Or will having patch files in composer be a manual concern? That's a really good question and my memory is a little bit rusty on this, but um, I'm 90 percent certain. I still remember Composer plugins because composer patches is a specific composer plugin But certain composer plugins. We don't know what they're about to do So we need to be really confident that we understand the consequences of using a particular composer plugin Because composer plugins in principle can do anything they want somewhere on your file system Which means it's highly risky for us to execute arbitrary composer plugins During this process However, we all know that many projects many triple sites are using patches So we are taking extra care And we're going very far in making sure that composer patches the plugin is correctly installed We're making sure that when you're for example updating from Drupal 10 1 1 to 10 1 2 just saying A example that the patches that you had applied are still applying And that the entire process is effectively working correctly And that's one of the things that automatic updates is indeed going to be checking for you So if the question was more about is it I think the question was specifically about the patches that I once applied Are they going to continue to be present? The answer is yes. There is extra validation to make sure that we do not break that case But it's possible that a certain core update, for example Would mean that the core patch no longer applies And that's the thing that would be that detects automatically then that we don't break your sites You would fail the validation check. Yeah, the readiness check would tell you Oh, we can't automatically update because you have a patch that's no longer valid So then the manual sub would be to Do it manually because you would need to point to a newer version of the patch that would be able to apply Or hopefully that patch has been committed and you can just get rid of it. That would be magical Other questions I'm just Okay, how will this work on platforms with read only file systems or like major Common platform hosting providers, whether it's the aqueous the pantheons and things like that um It won't Those hosting platforms would need to provide alternative integration. So by default automatic updates would Need to be able to write to a separate place in a file system That's one of the readiness checks that nil has mentioned If it can't then it cannot operate safely because it cannot do a sandbox in which it's verifying that everything Is in good order So it is possible for any hosting platform to Provide an alternative to that for example, I would imagine that you would like just already mentioned Generate a merge request or pull requests against your github repo your git lab repo Whatever the system is you use And that would then be the time saver, but it would not be automatically deployed. It couldn't because The hosting platform in this case would be preventing that from happening We did talk about this a lot when I worked for aquea because Obviously aquea is not going to allow you to write have your application writing to the web server There's a there's a couple of different options you can like Have it run in a staging environment And then just deploy from that Or you can use the apis that it provides. It does have like a full api To integrate it with your existing cicd stuff and I think Lee Rowland's from previous next did kind of a trial run Of this for us with because previous next is also is not going to let you know The web server write to the file system And and give us some feedback and improvements to make based on his initial testing We expect we'll get more of said testing once we get to beta I can imagine a world and what this looks like is a these platforms either Providing to their customers or allowing their customers to configure Yeah, a ci pipeline step that runs and says we've detected an update We've attempted the core automatic update process the output was an artifact that looks like it works And you know a one-click deploy or even say if this pipeline succeeds a deployment from there But that'll be partly up to those platform providers to choose how they want to implement it So that said most of them all of them that I'm aware of Have been aware of this initiative and of the technology underneath it So they're hopefully working on their roadmaps for that kind of integration and really quickly if I can pause quick How many folks host on like a large dedicated Drupal specific hosting platform if you raise your hand real quick in the room Okay, and how many are here partly because you're interested because you're rolling your own infrastructure and wondering kind of how this can help your sort of team And for everyone who didn't raise your hand, do you want to show it like what kind of case that is for you? I'm just curious Yeah Okay, well Yeah, I was gonna say You know if you have a ci CD pipeline or testing integration testing of the site The ideal world we would all have You know tests for if the whole website works together like Yeah, get that automating updates and use the parts of this that are good for you for that But yeah any additional testing for if you have it in your pipeline Use it. Okay. Checking the app here again. We have I think Five minutes ish to go for additional questions No more in the app. We've got one here, please It's not even on A little closer to the mic if you would I don't think it's oh it's on actually Hi, it's james from the history channel here So one of the things that we still get comments on using Drupal Is around Drupal 7 and what a horrible upgrade process that was this seems Amazing, you know what's coming down the line and to go back to the Drupal village Comment at the start of the the Drupal con and mentioning around, you know 62nd website builders one-in-one, you know wicks square space. Yeah, you mentioned around re-education of And reintroduction for the Drupal community But what about external once it gets to a point where it's in Drupal core Is this something, you know all the talk of marketing that will be used to help market Drupal to show that it's more user friendly to smaller businesses I think it would be stupid for me to say no But it's my opinion that that automatic updates is critical to Drupal having future growth at all Right like it's it's it's more than just a feature. It is an essential initiative And missing functionality right now. So yeah, but I think there's more nuance to your question than that Which is to what extent will it be part of a core sort of charm campaign? To say, you know, have you looked at Drupal lately? To understand what it can do and I think it should be essential to that I think You know, we are up here mostly as not the promote Drupal initiative or some of the marketing folks But in touch with them And I think you're right that one of the things that actually we do this a lot in Drupal is we ship something Extremely powerful and extremely cool And then the next day we've moved on because we have something else to do And we haven't talked about it yet and I think that is in fact going to be crucial But yeah, this is something that you know before we go all out on marketing like it needs to sink in get out of the beta phase and You know get all the use cases where you know, we're gonna start with Cores automated if there's no database updates like get all the other use cases So, you know, we don't want to tell people market and say hey everything's automatic updating and have that be lies But we'll get there what we're building has we're building something that doesn't exist elsewhere in the php ecosystem Like the word presses auto updater It does not do the things that we're doing It's it's new to composer everywhere So it is actually a really huge thing from an engineering perspective. It is very exciting But yeah, we're kind of we have to make sure that it works Yeah And you know, we I wanted to chime in on one thing just like it is a huge thing Like I joined at the beginning of the year and I worked on it for six months and I know a fraction of it It's it's such a big thing with the the libraries that are separate that are not triple specific that are integrating with composer The php tough validation. There is so much going on. I've never even seen the code Like there are so many layers of abstraction that we need to build on for this thing to be understandable at different layers Yeah, it's it's mind-boggling to me that these people have been working on it for so many years. I've only been there for a blip Um, I think I'm gonna ask my own question. Perhaps unless anyone has one that's really burning, which is in our last two three minutes If people want to get involved if they want to somehow contribute to this What are ways that they can do that? What could they do tomorrow? What are things that we'd like them to take a look at? Um, I think it would be great if you Install the automatic updates module locally gave it a try Specifically installed an older version and observed whether it worked well for you thoughts on the user experience On documentation anything and everything yeah And if there happens to be anyone in the room who's extremely knowledgeable about the batch system, please find Whammy and talk to them about that issue Yeah The question let me repeat Oh Well, I'll save your voice for one sentence. The question was would this ever happen for major version updates? Could it be 11 to 12 or whatever? It's feasible if you all of your contrib modules are using non-deprecated apis It's not an architectural limitation. It is a Policy decision not to allow that but theoretically it's possible and You could turn it on we just need we need to go a ways with the ecosystem for that to be feasible get um, you know More contrib compatible By the day the major is released and so forth, but with rector. We're heading in the right direction. Yeah Okay Real quick Thanks Maybe this is hopefully a one sentence answer But um, if I wanted to still do updates manually Could I use the wonderful new like console command and stuff to do the readiness checks and run the updates and things Without it, you know still doing them manually so I see jesse nodding. Yes, but i'm not sure that that's actually true And maybe i'm out of the loop on that It's just attended updates, right? Which there's a button for Okay. Yeah, I guess that's true. Yeah, it's like manually triggering the system Yeah, yeah console command instead of clicking the button in ui. You're right. Yeah, that's absolutely supported So yeah, you can test that way for sure and you can think about again Do you want to integrate something along those lines into your own already established deployment workflows? You could begin to explore that even though we're still doing some work. So Okay, well, thank you very much for coming. We really appreciate your time Thank you again, thank you to the speakers and contributors Please come find us during contribution come say hello. We appreciate it very much. Have a good rest of your day