 I think it's half past, so we should start. Welcome, everybody, on my session for Project Update Bot, R2-Drupal 11. My name is Björn Brahler. I'm CTO at Swiss. I'm core maintainer for JSON API and maintainer for Project Update Bot, and also a board member for the Dutch Drupal Association. If you ever want to find me or contact me, just find me on Slack. I'm pretty addicted to that, or Twitter, or drupal.org. Swiss is a Dutch digital agency from Leiden, the Netherlands. And we do sustainable digital transformations. We mostly do that for non-profit, government, and health care organizations. And we really love our automated updates. We tend to update to new versions of our sites in about a day, and we love to bring that power to Drupal also. So Project Update Bot, is it a good bot? Yeah, it's a good bot. So if we look at how we're doing right now, a lot of the top 1,000 modules are ready for Drupal 10, about 84%, which is great. Project Update Bot posted about 7,200 issues on the issue queue. And well, almost more than 2,000 have been fixed, or close as fixed, and there's about 500 who are RTBC. So we're doing pretty great. If you look at that compared to Drupal 9, you'll see that we started quite a lot earlier than we did in the 8 to 9 release cycle, which is a good thing. But it still only was about six months before the release of Drupal 10, which is a little bit short. So I talk about the Project Update Bot, but what is this guy with, like, 4,500 issue credits? Unfortunately, his profile gets a 500 error if it's too busy on Drupal.org, because it has so many credits on so many different issues. So Project Update Bot is the phase of project analysis, and it's mostly a collection of powerful tools to help modules upgrade to the next major version of Drupal. We have PSPayStan. We have Rektor combined with upgrade status, and a few projects around that, Project Analysis. That is the glue of it all. The Update Bot, which is the phase, and the deprecations dashboard to help people understand how we are doing in our upgrade path. So some short info on the different tools we use. For one, there's PHPStan, which stands for PHP Static Analysis Tool, and it finds bugs in your code without writing tests. That's not something I would recommend, but that's at least what they promise. What it does, it analyzes your code and reports on things like wrong function arguments or wrong types of variables, or the usage of deprecated code. PSPayStan Drupal is an extension that helps PSPayStan integrate with Drupal better. And at any time, want to use it yourself, I would advise to use Drupal Check, which does a lot of configuration for you, and enables you to use PHPStan and your projects pretty easily. Another tool that's used is Upgrade Status, which is a module that tells you about the status of your Drupal installation regarding the next major version. It tells you things like how is your platform doing, where you're running on, and how are your modules doing in regards to the next major version. It also tells you helpful things like where can I find possible patches, or is there Drupal 10 release for your modules available. The next tool is Rectorm. Rectorm promises to turn legacy code into valuable and sustainable code. Basically what it does, it's a way to use code to reflect your code. So for example, in build, it has stuff to support new versions of PHP, so you might need to upgrade from PHP 7 to 8. For some reason, it can help you with that. But it can also reflect your classes or method or functions to new signatures and help you in that way. And that's the core of what we do with Project Update. Well, to give you a little example, this is a configuration for Rector, which tells it to add an argument to a class. So if you run this through Rector, it searches your code, it searches for class that might extend the base class, adds the argument, and everywhere where the methods is used, it uses that argument also. So that's a really handy way to create new maintainable code from the code you use. In order to have it work with Drupal, we have Drupal Rector, which is mostly a set of applications that can be fixable with Rector. So if new deprecations come out, there's a configuration written for Rector and posted there, and from then on, it's possible to re-factor your code there. So basically Project Update, but is the phase of project analysis. It uses loads of tools, combines them towards helping module retainers get their modules ready for the next version of Drupal. So by their powers combined, I am Project Update bot. Behind Project Update bot, there's Project Analysis and Project Analysis automates the data collection and patch generation for all the modules, and that's quite useful. Automation is important because Drupal really needs its modules. Especially if you look at site builders, they need modules to extend the functionality of Drupal and make sure that it's usable for them without having to write too much code. Also a lot of the modules are pretty laser focused, are small and do a small amount of things. This means upgrading them to new versions of Drupal is quite easy. It's not a lot of work. But we want to make that work even less and make sure and keep the maintainers dialed in into the new versions of Drupal. So in a nutshell, Project Analysis is just a set of scripts. So a script to install and check and patch modules. It analyzes all Drupal.org projects that are compatible with the last version of, last major version of Drupal, creates patches from the updated codes and stores the analysis results for usage in other tools. And nowadays it runs on GitLab runners, which is fun. Last year it was migrated from the infrastructure of the Drupal association using Jenkins to GitLab runners. It runs for about three hours. Nowadays when we started it was more like five or six. So things got less heavy but there's also less to do because a lot of modules are ready for Drupal 10. What it does, it processes about 10,000 projects, might be a little bit less right now and it splits it to 50 separate jobs and does it as parallel as allowed. This did mean that I did break Git.drupal.org a few times when developing this. So I'm sorry if you couldn't check out Core at some point. There are three steps in that process. We prepare, we analyze, and we publish. Let's look a little bit in how project analysis does that. It starts by just installing and enabling a project, yeah, a module. Then it runs upgrade status to check for deprecations in that module and saves the XML output. That output is something like this, which is that in this file there's a deprecation we need to fix and other than that your info.jammel doesn't require the correct core versions. So then decides, do we need to run Rector or not? It's a deprecation we might be able to fix if we run Rector on this code. In this case, yes. So if so, committed project as it is right now. So we know the current state of the module as is. Run Rector and fix the deprecations and store the output of that process. The fun thing because we commit is that we can just use git to know if there's changes to the project, if there's any deprecations fixed. So if there's changes, we run upgrade status again and see if the output is clean. So this could be a diff of such output. It shows that the line where deprecated method was called is now gone. So we're happy and we think, yeah, this is fine. We only need some core version requirements changed. So let's create a patch and be happy about it. And it does that again and again and again for every single project that it knows to upgrade. All dispatches need to go somewhere. So we need to store those. We store those as artifacts in GitLab. This means they are downloadable pretty easily at the jobs that are run there. But there's also a job to combine all artifacts into a single directory. So you can download everything if you like. You don't have to go through 50 jobs to find the module you are interested in. And they're also committed to a northern branch, a results branch. So we have a Git history of all the patches that have been made and committed over in during the time of the project analysis. And that's great because that's a really good way to, for example, debug how things are going or why a module stopped being Drupal 10 compatible all of a sudden. And a lot of times you see that a module might have committed some old code or something like that, but sometimes it bugs. So now we have data and data school, all that with data. But data is only, it's only gets valuable when it's turned into information. So that data in project analysis is, for example, used in the deprecation status dashboards which is maintained mostly by Gabor. Which gives a lot of statistics on how we are doing right now and how many modules are ready for Drupal 10. It's a pretty green blob right now, so that's a good thing. If you ever go there and you're interested also in how your modules are doing, it's also possible to get lists of the modules you may attain or someone else maintains and drill down into even the module itself and all the messages that are given by the analysis tools. So you have an interface to find out how you are doing without doing it yourself and that's great. Another tool using that data is the project update bot. It's some secret, sub-secret repository hosted in Area 51. It uses issue templates from project analysis to post issues to the Drupal.org issue queue. And what it does, it analyzes the results, checks if there's new patches through some hash magic and post those to Drupal.org. Currently it runs on the machine of someone, Ted. So it's not perhaps the most scalable solution but it works and it's at least secure. So that's about it for how things are going right now and what project update bot is doing right now. Let's look ahead at Drupal 11. I think the main goal for Drupal 11 should be to create a maintainable base towards that point. If you look at how things went for Drupal 10, it was a pretty rough ride for the contrip maintainers but also for the tooling maintainers. We started about six months before Drupal 10 was released that meant that it was a pretty high pressure cooker to get everything ready for Drupal 10 and to give maintainers the time to get our modules ready and get the code in, especially with the bigger modules, that's a lot of work and a lot of effort. One of the things we also concluded is that breaking backwards compatibility is a pretty bad idea. The patches, getting patches in was a little bit harder because suddenly you couldn't support Drupal 9 in some cases so you had to maintain maybe two versions but some people don't have the bandwidth to do that and that's an issue you might need to solve. We did successfully decouple from the Drupal association in the infer team, which is nice. Before that change, it lived in the infrastructure repository so getting things in is always a little bit of effort and the guys in the infer team were pretty busy doing GitLab stuff and making sure that we eventually can actually upgrade Drupal.org because that's a pretty important milestone. One of the things that's also, we should start doing this, start earlier helping the maintainers. Making baby steps towards the next major version of Drupal and not confront them with a big bulk of work like four months before the new version of Drupal is released. So if we go back to the graph of how we did for Drupal 10 versus Drupal 9, you do see that Drupal 9, all the tooling was developed back then so we started pretty late. If you look here's the release date and a little bit earlier, we started posting passion. For Drupal 10, that was about six months ahead which is way better but still not perfect. So it would be really nice if we could start here. With Drupal 11 slotted right now for release in August, that means we have the summer to prepare to start with posting patches and helping maintainers get ready for Drupal 11 and that way make the transition a lot easier. In order to get there, there's a few things I think we should do. We should start fully utilizing GitLab. There's a lot of new possibilities in our migration to GitLab that weren't possible earlier on the old Jenkins infrastructure and it gives us a lot of power to do new exciting stuff. We need to get better in tracking applications and making sure that the coverage of applications is solid, we don't forget anything and yeah, we have working patches for as many as we know and we have perhaps a place to find what we don't cover. And lastly, we need to find a way to ensure backwards compatibility and make sure that modules are able to support Drupal 10 and Drupal 11 alike in a single version. So if we have a look at utilizing GitLab, GitLab uses GitLab templates to do a lot of the hard work for module maintainers. So nowadays it is as easy as including a GitLab.cae that YAML, that's a hard word, would only include in a few lines and you're connected to the testing pipeline on GitLab for Drupal. It would be pretty great if we could move towards a situation where you can also, for example, opt into regular updates from a project update bar and run that on your own repository, which will make some things with access a lot of easier, for example, to create merge requests and stuff like that. And that's the second thing. Currently the project update bar does post patches on issues in the issue queue. We're slowly moving towards merge requests and using GitLab fully for the whole new code into module flow, let's say it like that. And that's something we should do also for the update bar. And that's some cool features to GitLab that might make this a lot easier and make the update bar a lot more maintainable. For example, push options. It's possible to push and set a Git option and say make a merge request for this, please. And it automates the whole merge request creation for you. Another thing is GitLab issues. I've been, I've seen drums say that GitLab issues is something that is coming soon, Tian. There's no definite date, but as soon as that is a thing, this will also make a lot of things manageable, perhaps in GitLab even more and create an ecosystem that is manageable by the whole community instead of something that's hidden somewhere in the dark corner of the internet. This would also mean that perhaps the project update but would move to GitLab or perhaps the whole function might be contained in something else and the name and the face might disappear and might be an integral part of the normal workflow of Drupal. So fully utilizing GitLab has a lot of possibilities and a lot of things that I'm quite excited about. Next up is the tracking of deprecations. If we look at how deprecations are, how this works right now, it's a pretty human process. I mean, we first have to find the deprecations and we have a nice change records. We have change records we can look at and we can go through and find, hey, there's a new deprecation and this does X and should do Y now. And that's great, but then we need to create irrelevant issues in the tooling around it. This could be up to five projects that might need some sort of update before we can support the deprecation in automated pipeline. Then the different tools need to be updated and someone dependent on each other so that's a little bit of a web, sometimes to get it out and about in the world. Then we have to release the new versions and run project analysis and make sure things work as intended. And lastly, we need to start up a laptop and get Project Optimus to update all the issues with the new patches, with the new deprecation, with the new situation. Then wait a little bit and we have profit, yay. So in order to take a step forward in tracking the deprecations, Matt McLean decided to create a GitHub repository that automatically creates issues for the applications from the change records. It's an easier way to start managing and start tagging what tooling needs updating and tracking the progress of that. Then Goal wouldn't be doing this on GitHub, of course. But with the current movement where we were moving to GitLab issues, we don't really want to automate against Drupal.org issues. This was at least a step in the right direction to make it a little bit more manageable and to allow other people to also help in tagging and tracking those changes. So tracking deprecations is something that's important, to work towards a way to know what deprecations are covered, to work towards a way to know what work we still have to do. And perhaps also for module maintainers to know, okay, there's still a set of deprecations I might need to look at manually because those might be there still. Lastly, but not least important is backwards compatible fixes. And that's a hard one. If we want to start supporting helping people during the whole Drupal 10 lifecycle towards Drupal 11, we do need backwards compatible fixes. These fixes would help maintainers keep the amount of work they need to do to fix deprecations small because this means you can just merge a new fix during Drupal 10 and have your module support either Drupal 10 or Drupal 11 without too much problems. This would also eventually mean that if we move more towards the Drupal 11 release that upgrading will be a lot easier. If we look at how core handles things regarding deprecations, a lot of the time where there's a new deprecation the old code path is also supported only with the deprecation warning of course. So there are some extra code supporting both paths and make sure that nothing breaks up until the release of the next major. Then in the latest miners, so for example in the Drupal 10 lifecycle it was 9.5. There's a full feature freeze and 9.5. The last release of 9.5 is literally the same as Drupal 10 but including, yeah, I know. The same as Drupal 10 for 97% let's say like that. But including the back, so in Drupal 10 the deprecations are just removed. This means that the upgrade is relatively safe because there's no big new code, there's no extreme changes or extreme new code path that haven't been tested or used before. And which would be really great if we can bring that stability and that path also to module maintainers. Without them having to fully grasp how to do that. So let's consider two modules. Let's consider bad bot which will support Drupal 10 in version 1.4 and version 11 in 1.5. And we have the module good bot which just supports Drupal 10 and 11 in the same version. How does this look when you upgrade your project? So by the time Drupal 11 releases and you have modules that all follow the pattern of bad bots things can get a little bit complicated. So when you need to upgrade you require a new version of Core with Composer because everyone uses Composer otherwise I've got to shoot you. And you need to upgrade Core but also a big set of modules in the same call. And I don't know how many people have seen this one. Conflicts, I don't know what to do. I'm truly conflicted on what I should do. We don't want that. So if all the modules would follow the pattern of good bot you can just update your modules as you should do regularly anyhow. And by the time Drupal 11 releases whole of CompTrip, I'm very optimistic here but I like to be optimistic, whole of CompTrip is already ready for Drupal 11, all your modules. So the only thing you really need to upgrade in your upgrade to Drupal 11 would be Core. And that's way, way, way less risky than it is to update the whole set. So in order to make sure we make Drupal 11 a lot easier we do need patches that are backwards compatible. Some vector already has support for things like this. It could, you can tell it for Symphony for example, you can say what versions of Symphony I want to support and there's some magic happening to make sure that is possible. But we also need that for Drupal to say, yeah, I need to support Drupal 10 and 11 in the thing I'm running right now and the patches would reflect that. So this good result in perhaps you have two branches. You have your current module version. You might have a next branch, let's call it like that, which is your same module excluding deprecations just as Core does. So there's still some work to be done to make this happen. Matt promised me he'll work on this on this summer. So let's send him some flowers and I hope it were possible to make this happen. And I think that if we do these three things fully utilize GitLab and make sure that everything we do for project opted bought for project analysis and tooling around that make sure the community can help in maintaining and optimizing that. If we make sure that we are up to speed of all deprecations and make sure that we know the holes we are digging for ourselves in the future that would be great. Nothing is as bad as just walking and falling into a hole without realizing the hole is there. Better stop over here. And lastly backwards compatible fixes which will really empower a lot of module developers to do the thing that's great for all the site owners and to make all the site owners fear the Drupal 11 upgrade even less than they might do right now. I did talk a little bit faster than I would planned. That's how things went. If you want to help out just join us on Slack in Drupal 10 readiness or Drupal 11 readiness come to Rector if you want to dive into complex code and you like a challenge or come to PHP stand to help there. If you are the maintainer of modules and you don't have a Drupal 10 release for all your modules go get that ready. There should be patches if not we can help. And I want to highlight one initiative Kristen has started recently as a Drupal 10 project adoption. What they are doing right there is they have a big spreadsheet of modules that people want to use but don't have Drupal 10 ready releases with some instructions to how to adopt a module. A lot of those modules are really small. The patches are simple but they just need someone to commit. And a lot of modules have perhaps fallen off the radar of the people who built it or they don't have any clients using it anymore or perhaps they even left the Drupal space. And that's sad and not necessary. So if you have a dog and you can also adopt a module please come say hi and do a lot of work. It really helps. So I'd like to thank you everyone for your time and I'd like to answer any questions you might have. Yeah, yes, back. Yeah, Ben has backwards compatible patches. That's mostly checking the Drupal version and using code path A or code path B to do the work. Yeah, that's correct. That's mostly what the plan is. Sometimes it's not possible though. There are some changes that might have to do with perhaps changes in symphony or other upstream changes which might affect some modules, but not all. So it's not gonna be possible for every single change that backwards to have backwards compatible patches. We're talking also about perhaps getting some utility classes into core to help with making it a little bit easier to choose code paths through code by using function references and choosing it for you based on the version of Drupal core. So work's being done. The code itself is not gonna be that hard I think but the support for that and making sure that the patch is generated for either backwards compatible or not backwards compatible. That's something that really needs some work and attention because we can start posting broken patches because that's a bad idea. Any other questions? Yeah, so the question is are there any plans to publish a report or to make available a report of what the bot can and cannot do right now? I think that it, oh yeah, so you talk about the issue that the bot post is that we can see what it does and what it doesn't do. I think making the process for the tracking of the deprecations better enables us to report on that and report on at what time did we support what deprecations? For example, 10.1 is about to release. I'm not exactly sure when but we're on release candidate X. So we're close. And there's a pretty big set of deprecations already if I look through the change records. I think it's really important to report on what the bot does and does not do. There might have been quite a lot of maintainers that just merged the updated bot's patches somewhere in the beginning of the cycle and assumed I'm done. But that's, I think that if we go towards a model where we post more regularly or update more regularly that it's also helps to move away from that image or that assumption. But it's really important. Yeah, I agree we need to have a place to know what was supported at what time so you can know. Because we're not gonna, when 10.1 is released not everything is gonna be supported right away. That's pretty impossible. Then we have to work integrate more into the release process. And that's something for perhaps Drupal 12 or 13. Yeah. Yeah, if you look at the status dashboard, what Kabora says is that in the results for the analysis for upgrade status there's always a list of things you might need to fix manually. So even if you look at the dashboard there's an overview of all the issues that still need fixing manually. So you can't see the state at that point or at the point by then or even use upgrade status in the model in the project yourself to see what deprecations are still left. But it will still would be nice to know how is the work being done on the deprecation going ahead and is there, is there perhaps a reason that there's no support and will there never be support or will there be support in soon? And you'll just wait for the next minor release. So the question is, so the question is can you run Rector on your own modules in your own website if I understand correctly? When you use upgrade status it can do that and you can look at your custom code and analyze what kind of deprecation you might use. So it's invaluable to also help you upgrade your custom codes to new versions to make sure you're ready. For example, in our CI pipeline that we use for all our projects we actually during our updates to even my new miners or new point releases we always include an upgrade status report in the pull requests we create for the code. So we have automated a lot of those things to know the state of the project at all times and just look through the upgrade history. So you can do that right now, yeah. The question is when is the timeframe for release for 11? The current goal is August next year with the standard. But it could also be December but there's some deadlines regarding symphony I think which force us to move towards more synchronized release schedule with symphony to make our lives easier. And one of the steps you want to do is to move Drupal 11 up a few months to eventually move to less cycle in July I think I'd say by heart, I'm not decidedly sure but we're moving up the release cycle to synchronize with symphony and make our lives easier. If that's all, oh, Ben. Technically it would be possible, sure but the rules will get, oh, okay, sorry. The question was a lot of the times right now in the patches, Rector uses the global Drupal static object to get services instead of using dependency injection which you should use always. That's a bit of a shortcut, let's call it that. And the question was does Rector support using dependency injection doing that or is it something that's too hard? The fact is that the easy way to work towards supporting the version is of course using the service, getting the services from the global object because you just need to change code in a single line. Sometimes a class might not even use dependency injection right now or there might be other issues. This will complicate the code for creating the patches. Technically it's possible but I think in order to do that we need to get more power from the community, have a larger set of people creating those patches, creating those Rector rules because creating those rules is effort, there's a lot of effort. There's a relatively small set of people really maintaining those rules and creating those rules and it's better to have white support of fixing deprecations than to have limited and deep support for fixing deprecations in a way that's really good. So that's something that the community really can help if we get more people into helping fixing deprecations in the future. If that's all questions, I'd like to thank you all for being here, and your attention and enjoy your DrupalCon, thanks. Thank you.