 Okay, I'm Simon Hobbs from Little Engine. I was, I'm going to keep this pretty tight and pretty straight and leave things open for questions. So I'm not going to try and try to explain a lot of the background detail on what I'm doing here. Why I'm doing it should make sense to the people who it makes sense to and please feel free to ask any questions you like at the end. So I've got the Drupal Slack open here and I'm just open to the bug smash initiative. And that is basically, I suppose you'd call it the way I would say it's an attempt to corral, help corral people and direct people and make them more effective at reducing issues in the Drupal Core bug queue. So when this started, I sort of thought, the usual thought is I'd like to do a bit more bug testing or maybe bug patching for Drupal Core. But then I faced the typical problem where I'm sort of not comfortable with what the latest is and it takes me a while to set up my environment. So I'd had this sort of few times of setting up a sort of my preferred kind of environment for doing bug fixing. And so I did that and all I'm doing today is just giving you a bit of a run through of what I've done and what I'm using for myself. So I have a repository, a public repository here. I'm just calling it Core Dev. I'll give you just a quick run through of what is in the repository. Well, firstly, there's a read me which maybe describes a little bit more about why I'm doing this and some of the tooling, but I just want to take you through, I suppose the simplicity of it. I've got an empty directory for any config that I might want to export and import into a local Drupal Core site. I've got a patches directory for just storing patches that I might create or need to store for my local site. I have a basically a templates directory for any sort of preferred files such as settings.php that I want to use locally. And then I have a lando file and a hui file. My lando file is going to help me run up my local LAMP stack. And I suppose this is where the lando bit comes into it is as my preference is to use lando. Nothing here is couldn't be done with just Docker straight, Docker compose or other tools. But I just have a very simple lando file which effectively is going to run a Drupal 9 recipe. It sets some configurations such as simple test URLs, sort of things that I always forget how to set up in the first place. And it creates sets of a couple of databases, one for a local test site. And then the other one is just separately set up for running simple test tests or running PHP unit tests. Otherwise that there's not much to the lando file. And then I have a very simple to get ignore which is just, which pretty much identifies how this is going to be set up. I'm not going to be committing config and patches that I'm generating. I've got a directory for Drush, vendor directory for Drush, which I'm not going to commit. And I've got a random setup of directories for the Drupal core project to be cloned into. You'll notice I've got three here. I'm actually hard coding everything around 911X because I'm doing, I'm interested in patching on the latest version of Drupal core. So it's not really abstracted. I've just set it up to do 911X and then that's what the directory is called. And then I've got, and then outside in addition to that, I have my composer Jason and that is just installing Drush. So one of the things about doing Drupal core development is, okay, you want Drush, but Drush doesn't ship with core and there's an issue that says maybe it should. But I really just want to have Drush, but I wanted to install it outside of my repository, my Drupal core repository. So I'm going to do, so basically this is all this is doing is giving me the ability to access Drush for this. And that works quite well. And finally, I just have an Ahoy file and Ahoy is just what I'm using to, essentially just to set up a bunch of commands that I'm going to do regularly. So, and I didn't have stuff where perhaps I shouldn't be able to do it better, but I don't know how to do it. So I hate the files permission thing that sometimes happens when you install Drupal and locks all of your directory. So I've got a command that does that, but I've also got commands that just a command to apply a patch from a URL. So that's basically the repository and the idea of that is to keep that really simple. I don't want to make it like this huge massive thing that does a whole bunch of stuff. I just want to, what can I set up there to have the minimum that I need to run up Drupal and to do a patch. So I'll just jump into a demonstration of that. So here, this, here I have the repository clone. So this is the way that I run. I'm going to have a terminal for that repository that we just looked at. And then inside that I have this 911X directory. And so I'm going to be, have another terminal. Oops, people. Okay, and I've changed something. Ah, yes. So I'm going to have another URL with just the directory that the clone, another sorry, terminal with the clone. And then in my IDE, I'm going to have two as well. And the first one is the outside one because I might want to add something useful into the tooling that I've got there. But then I also have actually another session sort of for the actual Drupal core because if I'm sort of, if I'm say looking for files or something, I kind of want to just keep it. I don't want to hit anything outside of this directory when I'm doing my development. So that works fine. So the thing that I'm thinking is when I want to, I've got 15 minutes and I would think I might be able to do a patch is I want to be able to do that pretty quick. So I don't really care what I've worked on before. And I'm happy. And basically I'm happy to nuke what I've got there because in theory, I've created a patch from the last thing that I did. So the idea is I'm not going to do the long commands like building and things. So I'm just going to do a Lando start to bring up my containers. You can see that I've got Nginx, PHP, got database, the main database and then test database. Okay. So I get this URL core dev.lando which I'll be using. So the second thing is, all right, I actually don't know what I've done with my Drupal core. So I just want to reset everything that I've done. So I have a command just to do exactly that. So in other words, it's going into that directory and it's just nuking everything. It's just resetting everything, banking sure that says vanilla as possible. So before you notice that I had a dirty git status here, what I should get now is a clean git status. Okay. So I'm back to square one. And I should be able to look at the top of that and see that the patches that I see that should be relatively recent. So it just helps forth. It's great. And then jumping over to Drupal.org, we're looking at an issue and I think I can have a go at this. I'm not going to do the actual issue testing and review. I'm just going to just apply a patch and just to demonstrate that that's been done. So I'll grab the last patch that's on this issue, which I think would be this one. So I've got it set up. So I just want to take that URL. I just want to apply the patch. So I have another command that's just, at this stage I could just be using git commands and this is actually the only whole command that I've got is almost just demonstrates that, but I can just go into the directory and apply a patch just with a git command. So what that's done is it's applied the patch and it's just given me a git status to show. So I basically to confirm that that patch has applied. If I do a git status in here, I get pretty much the same thing over here. And then I can test. And then so to look at, to actually then run that up, I just have a command to, sorry, how can I install? So what this is doing is it's basically saying, I don't care what's in the database. I don't care what was there before. You call that and we're going to install a new copy of Drupal. So once this is finished, it'll give me a URL to log in. At the same time, I'm just going to reset this for the demonstration. Okay, so I've got my installation in here now. So I'll go and have a look at that. So what I want to do with this patch is I'm actually, it's actually a patch to check for a new option on the date range thing. So I'm just going to quickly see that my patch has applied. So the first thing I'll do is just install the date range module. And so there's a command here to try to hide rush and all that's really doing is just making sure that the URI, like the directory options correct on the, when you, when a SSH is in, makes just make sure that everything's, the drive configurations there. So I don't, I can just run simple commands. So I'm just doing a drive enable date range. Date, date range. And the, the patch that we're looking at doesn't take long to demonstrate. So I'm just going to structure content times, if you mistake, add field, add a date range field, please. But you can see here that this is a default form without the patch. So grab the patch, apply the patch. And then if I refresh this, I get the new, this new option. And then at this stage, so I've managed to do what I wanted to do, which is I wanted to see the patch in action physically, I can then, and then the final part of that is, perhaps I would like to, you know, run the tests against that. So we want to see that we can run the tests that have been changed in that patch. So that's where we can just use Lambda SSH into the container. And so in the container, I'm just going to go into the directory where I think it's a, we need to go into call to run this. So, so I want to run vendor then PHP unit. Then I just going to have a look at that patch and I'm going to see what tests have been changed there. So we've got this entity test, a data range test. So copy that. Hopefully we can just run, hopefully this will work. We can run PHP unit and just run that file with those tests in it. And then that then we're ready, basically ready to go ahead and update the tests as well as the code. I think that is basically what I wanted to show you in a kind of a quick tour. And I wanted to open up now to questions from you about what you think, did you have any questions about the process of, about bug smash initiative, about the process of testing patches that you wanted to ask or about this particular repo itself. I'm not gonna, I'll let those tests just run as they go. Obviously it's good to be able to run tests just specifically for a single test or a single set of tests in a file because they can take a while. Hello, Sai, very nice, Prezi. Question, I really liked the way you were using Ahoy to get it with Lando. Question, why did you use Ahoy and didn't use the Lando true link? Is it because you keep switching between GavCMS projects and non-GavCMS projects or because there is a limit on the Lando side? Yeah, two, no, so there's two reasons. One of those reasons you gave is correct. So one of the reasons is just generally speaking, I prefer Ahoy, because if we do a project, any sort of project and a developer is doing any kind of command for anything, I kind of say, well, I would like to be able to run that command if I have to pick up the project and run with it. So we sort of just use Ahoy as just a central way of doing things. So I'm sort of a bit comfortable, I guess, with just using Ahoy for that. The Lando tooling I just haven't done a lot of probably because the problem was already solved with Ahoy, but I would love the, I mean, you know, a project like that, if someone came along and said, can I just set up tooling in Lando to do the same stuff? I would go for it, because as I say in the read me for the project, using Ahoy makes it less accessible to Windows users. So this project would be better with Lando tooling, I think, long story short. And on that similar note, I mean, Lando is not doing anything that, like Docker, you couldn't do with Docker Compose. And if someone came along and said, can we just chuck in a Docker Compose file as well? And some of our Lengen projects do that as well, because we don't, not all of us prefer Lando. So we've got Lando and got Docker Compose, which I kind of don't mind. I kind of feel like that makes everyone a little bit kind of across the different things and different technologies that are emerging and comparing them. So I can talk a bit more about the bug smash initiative and how people can get involved. Yeah, good. So how can you get involved in the bug smash initiative? So it's bug smash doesn't, in some ways bug smash doesn't do anything new in the space. It's like there's already issue queues, there are already testing channels and so forth. But it's a regular kind of weekly bug smash meeting where people can, where if you join up to Drupal Slack, there was a meeting earlier today, so you can basically discuss different issues that you're having around fixing bugs, what ideas you want to see, what bugs you'd like to see fixed, what perhaps what you're looking for help one. Then there's a bug smash landing page, which gives you a bit of a like a starting point to get involved. So I think the way I kind of see it is like come in here and look at the different areas that you might want to get involved in. And then you've then got the bug smash initiative space to really talk that out and say, I'd love to do more work on such and such or who can I help or is there someone, can I exchange patches with someone? These things aren't necessarily not happening in other channels, but bug smash initiative is a nice friendly place where people can start to get involved with the goal of closing issues. I wouldn't say more about it myself, I think. You can always talk to people like Lee Rollins, Laurelann and like say Pamela, who are in there, so where's who are here. So we've got Pamela and Lee are both here in this channel and they're both in the Australia NSEd channel. So if you wanted to get involved in bug smash initiative, just put your hand up and say you want to get involved. Thanks, Sai. It's a great initiative. I think there was more than 200 bugs smashed within a matter of couple of months. Yeah, I'd hope to see some actual visible reduction as a result of just people just getting in. And I think Drupal, I generally feel that Drupal Core is much nicer to get involved with now now that things like all the old test classes and stuff have been replaced. So everything's like runs off PHP unit. It's really clear all the functional tests, the unit tests and stuff that are in core is a lot clearer. It's a lot clearer to kind of get to know everything's really well marked in terms of deprecation. So it's really clear if you're a developer, you've got a lot more examples to work off if you're trying to write or update tests. So I tend to think like a lot of the really hard work has happened in Drupal Core and it's a good time to get involved in contributing. If you ever wanted to.