 magic. All right, welcome everybody. We are here to talk today about a plain English guide to the remaining Drupal 8 release blockers. So this isn't actually plain English, so if you are a lit major or something and have never installed Drupal before, this won't make any sense. But if you know Drupal 7 or you've done a little bit with Drupal 8, the intent is to kind of describe what's left in front of Drupal 8 to get it to release, because it's really hard to grok that list of issues and sort of understand what all the titles mean. So I spent the last like month reading issue summaries, so you don't have to. So that is what this talk is going to be about. So first I want to cover some facts. A couple of these trees already covered this morning, so I'll go through this pretty quick. When will Drupal 8 be released? Anyone? When it's ready. That's right. There's my little troll phase here. And then of course the follow-up question is when is when it's ready? Yeah. So when is when it's ready to a little more complicated? So it's sometime after this graph hits a zero. This graph is currently at 26 as of 15 minutes ago. It might be 25 or 30 now. I don't know because it changes a lot. What happens when that number gets to zero is we go from betas to RCs and then from RCs to 8.0.0. And so as long as that number of critical issues is more than zero, we're going to keep rolling monthly beta releases. So you've seen beta 10, came out a little bit before Drupalcon, beta 11 will come out May 27th. Yes. Something like that. So roughly monthly we try and get a beta release out so people can continue testing. If the critical issues does get to zero, I mean when obviously meant when. Anyway, then what we'll do is we'll start issuing bi-weekly release candidates. And what we'll do is align those with the Drupal 7 release windows. So Drupal 7 has two release windows. I don't know if people generally know this, but one is a security release, which I believe is the third Wednesday of the month. And the other one is just a bug fix release, which is the first Wednesday of the month. So we just had Drupal 7.37 go out last week. That's because it was the first Wednesday of the month. And there were a bunch of bug fixes that they wanted to get out there. So what we would do is coincide with those bi-weekly releases and do RC1, RC2, RC3 bi-weekly to get a faster testing cycle. And then while release candidates happening, we're really only going to commit critical fixes because we don't want the code base shifting around. That makes it harder to catch where regressions were introduced. So the hope is that the RC period can be pretty short if we find all the bugs ahead of time because we're going to only be committing other critical fixes or super, super non-controversial things like docs or things that will only make things better and not possibly break anything. And then it's not necessarily any sort of specific timeframe. We kind of agreed that, you know, as we monitor how critical issues come in. And if it seems like, you know, they're coming in at a rate and sort of in nature, meaning like a critical bug that's like, ah crap, we just missed test coverage for that thing. It was a one line change. Let's get it done versus oh crap, it turns out we can't ship with, you know, nodes or something, you know, like that would be a different type of critical issue. Will will set a release date at least three weeks later and we want a three week buffer because that allows us to plan parties. So very interested in that. And then the third fact I usually get is how can I help? Actually, most of the time I also get why aren't you done yet? And the answer is the same. If you have more money than time and you want to see Drupal 8 come out faster, the D8 Accelerate fund is a great place to put your money. What are we funding with D8 Accelerate? We're funding a lot of different things. A lot of these bullet points will also come up in the course of this presentation. But these are really big important things like performance improvements, security fixes, which are funding the beta to beta upgrade path, all kinds of really big important things to make sure that when Drupal 8 gets out, it's high quality, it's secure, it's performance and it does everything you need it to do. We're also funding a number of really key contributors. People who are involved in Cordova probably recognize most of these people. These are the people who have been pushing Drupal 8 for a really, really long time. And now it's nice because we're able to direct community funding towards their efforts. So that's really, really cool. So if you have more time than money, that's great. Here is what is left. Oh, one more thing on D8 Accelerate. If you donate $100 to my fund or more, I will draw you a little picture and tweet it out to people. So just a little thing because my fundraiser is kind of sad. It's got like $545 because I don't know businesses. So anyway, but it's sad but awesome. So anyway, if you want to donate some stuff there. So I'm going to run through the remaining critical issues. I have a little key. So the ones in yellow are upgrade path blockers. So these are ones we cannot ship a Drupal 8 beta to beta and soon RC to RC upgrade path without fixing. Those are probably the most critical ones to get out of the way because they affect data integrity. There's some stuff that it's just like, we can't progress making Drupal 8 easier to install until those are done. A blocker is the next thing you want to make sure is gone because those things block other critical issues from getting in. So until critical issue X is gone, we can't fix critical issue Y. Blocked is the inverse of that means it's blocked on something else. So we can't move on it yet. But a lot of times you can still, you know, say recue patches or stuff like that to try and get those things done. And then finally, triage are ones where the core committers meet about every two weeks and go through the list of criticals and really tightly make sure that whatever's in that list is actually critical. The ones with the little green fingers are one where we've talked about them and we know that they're critical and they're going to stay in that list. Others maybe get downgraded to major or maybe stay there. It's a little less clear, but there's still good things to fix. So let's start with configuration management because there's only one issue under, whoops, configuration management, which is this one to validate configuration dependencies before importing configuration. So how many people have used CMI in Drupal 8 before? Yeah, the people who wrote CMI have used it. That's good, yes. So, okay, a few people. So this slide is a lot. Let me just explain how it works. So you have your dev, you know, and you're clicking around and you're doing views and you're doing content types and doing all kinds of things. Every time that you click save, that stuff is being added to what's called the active store, which in Drupal 8 is defaults to being in the database, but it can be in your file system or it can be in lots of other places. When you're done configuring things around, you go to a configuration management screen and you click the export button. You can either export your entire configuration, you can export one particular configuration if you were working on just your module or something like that. That gets put into a tar file with a whole bunch of YAML files, which is kind of like info files except they're like a standard that we didn't invent. And then you move that over your production environment. You do the inverse where instead of exporting through the UI, you import through the UI. And what it'll do is it'll show you a screen that says, here's what changed and you can view a diff and see the changes and stuff. And you say, are you sure you want to do this? And you say, yes. And then when you do that, whatever happened in your configuration or the other site gets bumped into your production active staging directory and that becomes your new configuration. And for those who don't like using UIs, there's Drush integration for all of this. So what this issue is about is just before step three here, just before your configuration moves from staging to active, it blows away all of your existing configuration on your production environment, we're going to do all of the validation of the configuration dependency. So you don't end up with say pulling in a view that actually references a content type that doesn't exist yet, or something bad like that so that you could potentially end up with errors on your production website, which nobody wants. So that one is under active development, but if you're interested in configuration management, that's a good one to jump into. Multilingual is another area where there's a couple of issues, pretty much rooted from the same thing. So those are those, I'm going to post these slides after so don't bother writing down any note IDs unless you want to really impress people at trivia night. Yeah, good old 248-6177, man, that's the drag. So what is 248-6177 about? It's about the fact that in Drupal 7, the way translations worked is every translation was a separate node. So you had your English node over here is node one and your French node over here is node two. You can tell it's French because the cat has a beret. In Drupal 8, we use entity and field translation. So you can dictate on a per field basis whether something is translatable or not, but everything comes to the same node and the way you show the English versus the French node is you base it based on the language information in the request. And so that's nice because sometimes you don't want the French version to have a cat with a beret. Sometimes the French version of your article is exactly the same as the English version of your article and that it's a blog post about Paris or something and you still want the same image. So you can decide don't make images translatable so you don't have to keep uploading things over and over. Use the same image across translations. It's very configurable that way. However, the problem is there's a variety of UIs and core. One is the admin content view. Another one is the actual delete button on the node itself that assumes things still work the old way. So you see a button that says delete this translation. What would you expect that button to do? You would expect it to delete one translation and you would be wrong because what it does is it deletes the node which of course is all of the translation. So that is why this is a critical issue because it's a data integrity issue because you should not delete all translations when you meant to just delete one. And so there's a critical issue open to fix this. We have a whole slew of things around performance. Is anyone in here fancy themselves a performance nerd and or awesome person? Go find some and tell them to get in here. So there's a bunch of sub goals underneath performance so I'll get into each one of those. So goal number one is just simply figure out where Drupal 8 is slow. We know Drupal 8 is slower than Drupal 7. And some of that is just the nature of it's got more abstraction. It's object-oriented. And we have a bunch of strategies around how to combat that that we're working at to be towards. But some of that is just really dumb stuff. And so the way to find really dumb stuff is to help with profiling and benchmarking. So I'm going to give you a lightning fast tour of some of the tools of the trade that people use when they're doing profiling and benchmarking. And then you can sit with Wim Lears and he can explain it much better than I can. So XH Prof, this is one that a lot of people use. And what this does is it measures the wall time, meaning like if you looked at the clock on the wall, how long did it actually take for an entire page to load and it breaks it down per function. So you know that this function took this many milliseconds to or microseconds to execute this function inside of it took this much. And through that, you can try and find, you know, problem areas and things that are taking longer than others. It's neat because you can look at either just one function or every this function and everything inside of it. So you can kind of help escalate really bad performance issues. The UI is awful. You can see it there. My cat could design a better UI. But it is very powerful. And when I see people who actually know how to use this thing, use it. It's really cool. And then the other thing that's neat about this is you can show diffs between two runs. So you can say before the patch did this, after the patch it did this and that was a difference plus or minus of this many seconds. Flame graphs is a way of visualizing SHPROF data where it will take a variety of calls. So you can have one page load just really bad because that was the page load where they were repopulating some cache. This will take a variety of calls and then what you end up with seeing is calls that take a really long time or calls that happen over and over again will be longer on the on the flame graph. So you can kind of draw your attention to them if they're longer than what you expect. You can say, oh, you know, why is it taking, you know, this much of the total request time to like generate a block? That doesn't make any sense and kind of go in there and figure out what's happening. Apache Bench is another tool used for benchmarking. What that will do is basically simulate your web server being hit by multiple requests at the same time. So you can say do it with this much concurrency. Do it this number of times and you can compare before and after what you were getting on average, that sort of thing. So these are just a few tools that people use with benchmarking and profiling. And I'm unfortunately up against Wim Lear's right now who's talking about cool caching things. So I'll end that part pretty quick so you can go over there if that's more interesting. So goal number two is to fix the known areas of slotus. So obviously when we find dumb things and we want to fix them, the known areas of slotus only become critical if they meet a variety of criteria and some of it is, you know, it saves like I think it's greater than 10 milliseconds on a cold cache request. Some of it is, you know, this is something that has a pretty sizable improvement and it breaks APIs. We wouldn't want to do it after 8.0. And there's a variety of different things. So there's a couple of these that are critical. There's a lot of these that are major and they add up together to a pretty big improvement. And then the third goal is to render cache all the things. So the ability to take everything on the page and sort of render cache and stuff like that. So I'll explain this with a little diagram, although I see my slide transitions are a little wack, so this will be fun. All right. So Drupal 7 page caching worked like this. You start and you have a nice warm page cache. You go to your page and it's really fast because, you know, it's in the page cache and everything's cool. Then somebody like fixes a typo in a node somewhere, right? And then Drupal says, oh, somebody changed something in a node somewhere. Let me nuke the entire page cache because something somewhere changed and then you get to start warming the caches all over again, right? And so that's like really bad. Some people work around this in a variety of ways, like instead of using Drupal's default page cache, they use a null page cache and they put akamai in front of it or whatever, but it's like the default is not very smart. And the reason it's not very smart is it doesn't have the knowledge of all the things all the way down the request to know how to invalidate caches smartly. And so in Drupal 8, we've added a bunch of little things to help with this. So we've added cache keys. This is a way to represent what the thing is that you are displaying. So in your render array, you'll specify things like this is node, and it's five, and it's a teaser. So that way, if the node being changed is node five, you know, you don't have to invalidate node 11, because it's not the same thing. Cache contexts are a way to define under what conditions well the cache of this thing vary. So for example, some blocks show different things depending on your role. And some blocks show different things depending on your language. And some blocks show different things depending on you, the person, you know, Angie will see different things in her web chick block than just C's and hers. And then cache tags basically list out a reason for things to be invalidated. So node five, user three, taxonomy three, if any of those things change, they're all included in this piece of content. And that means this piece of content needs to be invalidated. What's nice is that the Drupal core APIs take care of this for you, for entities, and for a lot of, you know, sort of base systems, but it's really useful to know how it's doing those things. Because if you write your own contributed modules with your own special do Hickey things, this is really useful to know about. Because the way Drupal eight page caching can work then is start with a nice warm page cache, someone fix a typo somewhere. Because it knows it was a typo only on node five, it just clears anything with a cache tag about node five. And it instantly validates or updates the cache, you don't have to wait for this enormous cache warming process to happen. So it's quick. And it's precise. And that's what you want in a cache and validation system. This work is also enabling some kind of cool things like big pipe. So thanks to this kind of extra cache metadata that we have in Drupal eight, which is really nice. You can take a page that's really complicated, like a Facebook profile, and you can figure out stuff that applies across all users. For example, the HTML frame, the search box, the Facebook logo, stuff like that, that doesn't vary on a per user basis. But on the other hand, something like the block saying who I am, the status feed of all my friends, that stuff does vary on a per user basis. And so what big pipe allows you to do is basically prioritize the parts of the page you want to make sure is sent first, which in this case would be like the outer frame and the inner sort of status feed. So it looks to the user like it updated like that. And then the rest of the pages less critical can kind of filter in whenever it needs to. And there's actually a prototype for this in Drupal eight and we're hoping to get into core before we ship, which would be great. And then smart cache is another thing that we're working on, which is going to roughly double the performance of a page cache, including for authenticated users. Normally page cache only really affects anonymous user traffic, but this will actually work for authenticated as well. And the way that it works is when it doesn't find a cache entry, what it'll do is what it always does, which is, oh, you're at, you know, example, you know, comm slash foo, I'm going to go find the controller that foo maps to which in Drupal seven parlance would be like the page controller. I'm going to run the page controller and it's got, you know, like it runs some queries, it builds out the, you know, the render array does whatever other expensive things. And at the very end, it renders that out to HTML. What it'll do is it'll capture that HTML once it's been rendered in cache that so that the next time you come to that page, instead of going through the process of building out everything, you just go immediately to the database, you grab the rendered a cache and then you just dump it out to the browser. So basically you get to skip those two expensive steps. And that's really, really handy. It requires, though, a little bit of attention to how things are being built because anything that is dynamic, so say, for example, a new marker on a comment, which would be per user, or something like a, like the, if you printed the current date or something on the page down to the microsecond, because why not, right? Stuff like that, you need to put into a different bucket, which is currently called post render cache. And I think by the time we ship will be something different. But the idea is that those get little placeholders that get filled in dynamically with JavaScript after the fact. So if it's not part of the stuff the server needs to render out. Okay? So that was very complicated. If you want to listen to someone explain it much better, as I mentioned, Wim's talk is in the other room. But pretty cool stuff because this means that Drupal 8 is not only going to be able to not incur these weird performance penalties at random times like Drupal 7 often does, but it also means that we can improve performance both for anonymous and authenticated users at the same time. Another goal within the performance initiative is fast by default. And what is that? That means we've done things like enable JavaScript and CSS aggregation by default. We try not to load any JavaScript for anonymous users to keep page loads fast, especially on mobile devices. We put render and NAD caching in core. The page cache is actually enabled by default. And that's great because it means that Drupal 8 is going to be ready to go on a big kid reverse proxy cache like varnished or something like that. Wim has said that basically Drupal 8 ships with poor man's reverse cache. Like poor man's cron and Drupal 6. Anyway. So it's like it already works. Like poor man's varnish is in there doing its thing. But if you put a real tool like varnish in front of it, it'll just work. And you won't have to do any special configuration. PHP 7 is also in this bucket because it represents an 84% performance increase or so, which is really cool. And another thing that's neat, this was from Rasmus Lirderstock who invented PHP. And the other thing that's cool is fast by default makes Drupal 8 way faster than all of the other frameworks that he benchmarked. So we look really good on really stupid benchmarks where people didn't bother to figure out how to configure things fast. And that's about all I can say about that. It's cool, though, because a lot of people are like, yeah, whatever. I just turned on the page cache in Drupal 7. And if you do do that, you're fine. A lot of people don't know to do that. And a lot of people are going to get hit by this where their sites are slow and they have no idea why. And this is going to prevent that from happening. If you do want page cache disabled, we ship with an example that settings up PHP that you can copy into your sites folder. And that does things like you can enable twig debugging and you can disable the page cache and all that stuff. So if you're developing and you don't want to have to hit the clear cache button all the time, it will turn off caches for you. But it's an opt-in step that a developer has to do, because the understanding as a developer will be smart enough to know how to undo that versus a lot of less sophisticated users may not know how to find all of the various performance settings to make their site fast. All right. So another big area is security. Am I boring everyone? Does anyone have any questions? This is a core conversation, so feel free to shout out anything if it comes up. Yeah. Hip hop, not that I know of, although we've talked about the next version of test bot, being able to test Drupal in multiple alternate environments like hip hop and other things like that. But at the moment, I don't think so. I think they're sticking to vanilla straight stock PHP. But you could be that person. Because I'd love to see it work on hip hop as well. Yeah. All right. So under security, one goal, I think this is a pretty good goal, is don't shift with security regressions from Drupal 7. It's probably a good one. So there's one essay back port that's giving us a hard time. This one is more of a behavior question. It's like, well, yes, technically Drupal 7 didn't do that, but is that really a security hole or is it not? So anyway, there's some discussion happening in that one. And this is a new bullet point, which is before we ship Drupal, actually before we do a Drupal 8 RC, we're going to make sure there are no major or critical Drupal 7 or Drupal 6 issues remaining in the private security tracker. And the reason we're doing that is because as you may or may not know, Drupal 6's end of life happens three months after Drupal 8.0 ships, whenever that is. And we want to try and cast it off into the ether with as much stuff fixed as possible. So hopefully, if it takes a while for people to move off of Drupal 8.0 into something else, they won't get hit by anything really nasty. And so that is also going to be a blocker for Drupal 8.0 as well. So if you're on the security team, keep your eye on that list of issues and just make sure that if any come in that they're fixed in time. Another goal underneath security is safe markup everywhere. And you're like, what is safe markup? And I'm so glad you asked. So safe markup means if some lovely person fills in something like this in a field like a user profile field or something like that, if you're careful, and you call function like check plane check markup filter XSS filter XSS admin T with the at sign or the percent sign, or any of these other little things, you're fine. And what will happen to alert moa ha ha, whatever, is it'll just get HTML and de escaped and you're fine. And there's no security vulnerability. If you're not, and you just did a print dollar sign field, blah, blah, blah, whatever, then you get a JavaScript alert. And then hackers ruin your life, which is a lot of fun. Drupal 7.0 and below really relies on the developer to be sophisticated and understand the context in which they're working and how that output should be scrubbed in various other things. So in Drupal eight, we've enabled a feature of the twig theming system by default, which auto escapes any input that's put into it. So now what happens is if you forget, you get ugly double escape stuff hope showing up in your user interface, which is bad, but not as bad as hackers ruining your life. So you know, and then in order to avoid the double escaping, there's a bunch of different ways you can do it. The recommended way is anytime you're outputting some kind of HTML from your module, you should use a twig template, either a proper twig template, or we have this kind of called an inline twig template, which is sort of like an in sort of like a render away way of doing it like a pound markup. There's a bunch of other ways, but you should not use safe markup set, which is the internal way that twig determines that something is safe to go. And so we need to fix a bunch of places in core where we sort of cheated and did that before we release. The other goal under security is a secure REST API. And a few of these are related. The entity forms get validation of fields that are not in any form display. That is a weirdly worded thing that is like why is that under REST. The reason that's under REST is because there's a lot of validation that happens in Drupal 7 in form validation functions. So like when you hit the save button and it goes and it says, oh, did you actually fill in a name? Oftentimes people think in a very form centric manner. And so they're like, oh, let me check the form field and see if that was filled in. The problem is if you're doing that same submission through a REST API and you're trying to call an API function to do that, anything that's in a form validation function gets bypassed. So like if you talked to Greg Dunlap who wrote the services module for Drupal 7, form validation functions make him want to shoot things. So the idea is that we need to move all the entity validation out of form validation into the actual API so we'll get triggered from either the form or the REST API. This other one, external caches, I'm going to explain what that is. So how REST works currently in Drupal 8 is we use what are called accept headers to do different things. So we said I want HAL JSON version of that thing. And we keep the same URL regardless. So you can go to node slash 1 and it'll default to sending out HTML or you can condone slash 1 and give it an accept header of HAL JSON. It'll send you back JSON. And that's a very proper REST way to do a REST API. The problem is browsers and a lot of CDNs don't always work that way. And so then what will happen is if say a JavaScript routine went and hit a URL to get a JSON request, when a user goes to do that, they're going to get this in their screen instead of HTML, which is not what you want. And so instead of doing the proper REST way of doing things with accept headers, we're going to keep that as sort of an opt-in mechanism, but the default is going to be using most likely query string negotiation. So you'd actually do a question mark underscore format equals whatever. And it would use that to determine the format. And the nice thing about that is, well, there's a few nice things. One is it's a lot easier to hack on REST stuff because you can just type stuff in your browser and you'll get different results. So it's nice from a DX point of view. When things are at different URLs, that means we don't have caching issues because that's a different URL than on question mark format HTML or question mark format XML. So we won't have things like CDNs being silly and sending you the wrong content type. And then the other thing nice about using query strings is because it's just kind of got common thing in web that if a query string makes no sense, it just ignores it. So we can do the same thing here and send HTML by default if we don't know what you're talking about. So that is where that looks like it's going. I think that issue got to RTBC at least once or twice in the last couple of days. So hopefully it'll be ready soon. All right, then there's some Drupal.org stuff. Do we have anyone from the DA in here? All right, I get to smack talk. I'm just kidding though. They've been great actually, because this is the list to begin with in that Drupal 8 adds a whole bunch of new patterns like, you know, PSR4, YAML, all these new kinds of things. We wanted to make sure Drupal.org was mobile friendly before we shipped our mobile friendly CMS on a site with scroll bars out to here. That would have been pretty embarrassing. We also wanted to support semantic versioning. So for people who don't know, after a Drupal 8.0 ships, every six months we're going to be doing new, they're called minor releases in semantic versioning, but effectively backwards compatible feature releases. So in 8.1, we might throw panels and media module in there. In 8.2, we might put path auto and something in there. So we've already hit three of those. They're off the list. So we've already got Drupal.org support for all these newfangledy things. We've got Drupal support now looking pretty decent on a mobile browser actually, and support for semantic versioning. The last two are translation support for Drupal 8 and automated testing for all supported PHP versions as well as supported database versions. Oh, I had a slide about this. That's semantic versioning. Yay. Backwards compatibility preserved. But my favorite thing about this semantic versioning thing is that the people who like working on core and the people who like using Drupal will both be, not that they're not the same, but there's not quite. There are a few core developers who don't build Drupal sites and stuff anyway. But they're all working in the same place. And so people who have clients who have bugs, real bugs, get them validate against the people who are actually working on core to fix things. And that's great because it means better user feedback. We're not inventing APIs in the hopes they'll be used. We actually get real world validation of all this stuff. And we will eventually make a Drupal 9, but this will probably be multiple years in the future because we have to save up enough really cool things in order for that to make sense. So everyone can have a big sigh of relief about upgrade paths and such. Translation support. There's a bunch of words on the slide. Don't worry about it. Essentially localize is still on Drupal 6. We can't keep that on Drupal 6 because as I mentioned, Drupal 6 is end of life after Drupal 8 comes out. So that would be silly and sad. So localize is almost ported to Drupal 7. I believe Oliver Davies is here and he'll be at the code sprint if anyone wants to work with that. What we mainly need with the localize port is just help testing. So if you've ever done anything with translations or you'd like to try, go find Drupal association folks at the sprint. And then a lot of this is just Drupal 8 shift with new things to translate. So Drupal 8 translates configuration, which is a new thing. It didn't do that in Drupal 7. So just building in support for that. And then another thing Drupal 8 ships with is the ability to go out and retrieve the most up to date translations through the UI. You don't have to go over to localize and go get them. It'll do it through the UI automatically. We need service side support to make sure that it knows which is the right translation to download in that case. And then the other thing under Drupal.org is Drupal CI, which is the modernizing test spot initiative. Was anyone there this morning for Jeremy Thorson's amazing rendition of simple tests sung to the tune of yes. That was like my most amazing Drupal come moment ever, I'm pretty sure. But anyway. So this is simple test version. Not 2.0, because that would be undersigned. It's like version candlestick monkey. I don't know. It's just like phew. And there's all these boxes and I don't really know what all the boxes do. But effectively, what happens is we use instead of using Drupal as a continuous integration environment, which it's neat that Drupal can be a continuous integration environment. It kudos to Drupal for being able to do that. But the Venn diagram between people who like using Drupal and people who like using CI, and the people who want to use CI with Drupal powering it is like two people, maybe three. So this uses all the things people normally use for CI. It uses Jenkins as an ability to move things around. It uses a Sylex API to talk back and forth between a result server, which is running Drupal 8, actually. And then what happens is when they spin up test spots, they're just using docker and puppet and words I don't revagrant is in there somewhere. I don't know. Anyway, but all these DevOpsy words. So DevOps people know what I'm talking about. I don't know what I'm talking about. But it's stuff that normal people would use for this sort of thing. And it's nice because a lot of these things can be used to do like say development environments of Drupal.org. Or people can even, I mean, this is all open source stuff, so you can take it and run, you know, your own, you know, local Drupal CI. I think MongoDB was using this to test Drupal 8 against MongoDB and such. So it's cool. So if you want to help test spot candlestick monkey, then you, if you're a tester, there is a nice readme file that you can go through and actually download and get your own local test spot. I've been testing on Mac. I think people test on Linux. If you have Windows, that would be really interesting to try and see what happens. It should work okay though because it downloads like basically your own Ubuntu Linux installation that knows how to do everything and stuff. If you're a designer, we actually have help. We need help because our results site right now is just using Bootstrap with an emphasis on Boo. No, I'm just kidding. I've heard that designers hate Bootstrap. So anyway, it literally is just stock Bootstrap. So we wanted to look a lot more like Drupal.org blue cheese and stuff like that. So if you know theming or HTML or CSS or that kind of stuff, this is actually an area you don't need to know about any of that crap I just talked about, but they need help on the theming side because as you can probably imagine, people are super good at like puppet and things are not so great at Photoshop. So, you know, core developers, they need help understanding why tests are failing under certain environments. And so if you could help get one of these running and test it out on your local and say, oh, obviously that's because it's Postgres and it has a weird thing with ordering something. I don't know anyway. You know, that would really help because these guys are DevOps guys. They're not core guys. They don't know about the core stack. They don't really even know about Drupal 8 at all in some cases, but they know that the tests are failing under this environment, but not that. So having some sort of insider knowledge as to what that test means and what it's trying to say, that's really, really helpful. And then if you're a tinkerer, one of the great things about this platform is can be infinitely expanded. So one of the things we've talked about doing is once we get the basics open running, like making sure that Drupal 8 test pass and PHP, you know, 5.5, 5.6 and 7, as well as, you know, Postgres SQLite and my SQL is like, oh, let's try making it work on hip hop. And let's try making it do be hat testing. And let's try making it doing automatic coding standards review and all kinds of other crazy ideas that you might have. So again, the Drupal Association folks are there in the sprint. If this is kind of an area that you're familiar with, feel free to join them. They would be really happy about that. Another area is the upgrade path. And upgrade path is a really, it's an overloaded thing. So I want to explain a few vocabulary terms again. So in the past, when you upgraded from Drupal 6 to 7, you would run the update.php script, right? And what would the update.php script do? Break! Yes, often that is true. It would break. But more than break, what it would do on the way to breaking is it would take your production database, and it would modify it in place in a horrifying manner that you don't even want to know. And while it did that, your site had to be in maintenance mode. So when Drupal 7 or sorry, when Drupal.org moved to Drupal 7, the site was down for 18 hours, because we have over a million nodes, over a million users, and over two gazillion taxonomy terms or something. That's bad, right? Because nobody wants that. And then if it fails, all you can do is restore from backup and pray to God that nothing important got lost. So we said we're going to knock that off. As of Drupal 8, we no longer support that sort of an upgrade path between major versions. So now a major version is a migrate, not an upgrade. And so we ship with the migrate and the migrate Drupal modules in core. And the Drupal 6 to 8 migration path is already in core, still has some work to do, but it's pretty solid. And then 7 to 8 migrations are in progress. They're essentially waiting until 6 to 8 is done, because then my understanding is it's a pretty shallow lift after that, because most of the stuff is actually the same. So major version of it is going to be a migration. And the nice thing about that is you build your site without any legacy cruft. And you can keep testing the migration for weeks if you want to, leaving your old site up and running. And then when you finally feel like you're ready to go, you flip the dock route to point to your Drupal 8 site and you have no downtime. So it's actually really, really nice. A lot of people honestly are doing upgrades this way, even though core doesn't support it, for all of those benefits. The upgrade path as in your fabulous update.php script will still be there, but it's only used for minor version upgrades. So 8.0.0 to 8.0.1 or 8.0.1 to 8.2.0, one of those, those will all be done with the upgrade path. We don't currently support an upgrade path in Drupal 8. So the official line is if you want to move from beta 10 to beta 11, you get to destroy your entire site and rebuild it from scratch, which is a really friendly line to business clients as you can imagine. And so we don't try, that's why Dries emphasized in this keynote, we don't recommend people actually use Drupal 8 yet. But at any rate, you can do it, and there's different ways to do it. So one of the, oh, I did this in the wrong order. But anyway, so what's left to support an upgrade path in core is basically two things. One is we need to make sure that we can automate it and automatically test upgrade paths as an important part of ensuring data integrity. So anytime a core patch adds an upgrade path, it's a requirement from a core process point of view that it also has automated tests to backup that it can work. And the problem slash opportunity in Drupal 8 is that not everything is stored in the database anymore, right? We talked about the configuration system and how it has stuff in YAML and has stuff in all kinds of different ways. And so the idea is we need to dig in there and make sure that we can still do an automated dump from a before and after state and compare the two and make sure that they work. So Andre is working on that as part is D8 accelerate, so that should hopefully resolve suit. And then the only other question is a policy question, really, which is when to support an upgrade path. The advantage of supporting it in core sooner than later would be, you know, obviously we can tell business people, you can stop destroying your site, every beta, you can now run up data PHP, which is nice. But it's a big velocity suck because that means from now on, if we commit any patches, excuse me, that require an upgrade path, we also have to block them until they have tests. And that makes fixes slower. So it's a policy discussion to a large extent with the core committers to try and figure out the opportune time. So in the meantime, to buy us head on both of those fronts, you can go to contrib and the head to head project. You can find it because it's got goats. So anyway, if you go find the goat project that actually has a beta to beta upgrade path, it supports both beta nine to beta 10. And I want to say beta seven and eight to beta nine as well. But I'm not completely sure about that. But that is where we're trialing this and contribute to try and flesh out what all the issues are before we put it in core and we have to actually support it. I saw a hand. Yes. When that's translated into French to the goats have braids. That's a fabulous question. We should enable translation on Drupal.org and find out. Yes. I could say all kinds of stuff because the DA people aren't here. Anyone else questions on that? Does that make sense? So in summary, major version upgrades, migrate minor version upgrades, upgrade or update dot PHP, but we're not supporting it until we can test it. All right. Also, we want to make sure that people can move off of the old stuff. So want to make sure that Drupal six to seven has a functional migration path as well or upgrade path as well, because we don't want anyone to be stuck on Drupal six. And as far as I know, there's only one critical D seven upgrade path remaining. And it's this funky thing you can get into. We haven't quite nailed down exactly why, but you end up with a situation where you have two copies of the same file in your files table and it can't proceed. So if anybody has Drupal six sites still kicking around anywhere, it would be really helpful to have your input on that issue. We also want to finalize the migration system one way or the other. So what's left for that is we want to finalize a migrate API, finish the Drupal six to eight migrations, because the way in which migrate is built is basically it will fall back to the Drupal six version if a Drupal seven version doesn't exist. So that means 90% of the Drupal seven to eight migration path is already written as part of the six to eight migration path. We focused on six to eight first because they're screwed when Drupal eight comes up. They're not. It's not like immediately as soon as Drupal eight comes out, your site is insecure, but we no longer support it with security updates. So we want to make sure they're protected. Then the next thing we're going to do is far to the seven to eight migration is we're going to focus on content first. So nodes, users, taxonomy, that kind of stuff. And then finally, we want to put in a migration UI. So the ability to bear a UI very similar to what update to PHP offers right now, except you would enter your old database credentials and your new database credentials, and it would suck things over. And then the last thing as an if we get to it basis would be the seven to eight config migration. So this would be like your views and your block visibility and stuff like that. So I'm hoping we get to that stuff, but it might be stuff that filters in after 8.0. And then we have the final countdown. So there's a few things that end up if we get down to where this is the last or one of the last five or so critical issues, it sort of triggers this variety of things. So one of them is we have a variety of issues that are in the fix it or Nixit category, which means either we need to fix this stuff or we're going to put that back into contrib until it's ready to go and then pull it back into core later. So one of those things is alternate database support. I have SQLite highlighted in red because it's embedded in such a way to things like the test bot and stuff, we can't actually remove it easily. So we're basically stuck fixing that either way. And then Postgres is also in there. And there are people working really, really hard on this. I see Jared Smith is in the audience. He's been working a lot on Postgres and SQLite too, I think. So yeah, so if you want to join up to support alternate database systems, that's amazing and fantastic. And there will be work on that at the sprint. The other thing that we really need someone to care about because right now nobody who works on core cares about it is the module installation and update UI. So if people use this, it's cool. It's like you can go to install a new module from within the application, you copy and paste the URL to the module install, and it'll actually go out, put it in there, and you can just enable it without having to stop everything you're doing and run Drush or whatever. However, we don't have anyone working on this right now. And there's a couple of critical issues with it that make it not work. If we can't fix those before we get down to five or so critical issues, it's going into contrib, where frankly, it's probably never going to come into core again, because if we can't find somebody to care about it now, I don't know if we're going to find somebody to care about in contrib. So last chance, if you want to save this poor UI, there's a patch. It needs testing. It's like, it's close, I think, but yeah, it needs some work. And I think we kind of talked about this, but we need to figure out what the level of migrate support is in Drupal 8. So like I mentioned, migrates not officially supported yet, because we're still actively working on it. We made a release management decision that it's not going to block the release of Drupal 8. So what will happen is 8.0 will have something in the release notes that indicates, you know, six to eight upgrade passers, or migration pass reported, but seven to eight is not yet. And then we would make every effort that by 8.1 or one of the later releases, we would support a full migration path. Most people on Drupal 7 don't really want to move off of Drupal 7 anytime soon unless they're like people like the people in this room who have little blogs and like, I want to use Drupal 8. So I'm not sure exactly where that will end up. We do have some people really working hard on migrate though. Ryan Weel is here, I know at this sprint and Aqui has also hired an intern named Adam who's awesome to work on migrate stuff. So hopefully, hopefully we'll see this shape up before 8.0 as well. We also need to update all the things. So there's a bunch of PHP external PHP libraries and JavaScript libraries. We just need to make sure they're all in the latest version, because we don't want to get into an embarrassing situation where we're shipping with a version of jQuery from four years ago. Not that we know anything about that Drupal 7. Anyway, so I want to make sure all of our stuff is updated so that it's the latest. And then we need to revisit the, revisit before release candidate tag. This was a lot of places where we just kind of thought, I'm a little 50-50 on that. I'm not quite sure if this is a good idea or not. So let's do it and we'll tag it for review later. And then some of it is things that we want to make sure we do right before release. So we're going to try and make this list as small as possible over the next couple of weeks and make sure that doesn't hold us up too bad. So in summary, fix a bunch of performance things, security things, we got some multilingual as well as some configuration management stuff. We want to do some future-proofing, Drupal.org, upgrade path, and the final countdown. So that is what's left to ship Drupal 8. See you at the sprints. So questions or comments or clarifications or yes? Hi, Angie. So imagine a scenario where we figured out this magic thing like Mozilla did and we had a $300 million budget to work on our open-source project. What could we do to make it so that we never had a really long release cycle? And how did this list of things that we're working on forever? Yeah, that's a great question. And I think I don't need to repeat that because he said it into the mic. But what could we do with a $300 million budget so we never get into this scenario again where Drupal 8 is taking four plus years to come out? I think honestly the release management changes we're doing subsequent to 8.0.0 is going to prevent that, I hope, because it fundamentally shifts the entire way Drupal has been developed to this point, more in line with what other projects are doing. So what I would do with a budget like that is I would probably hire a core group of people to do the really unfun stuff, like making sure that tests are written and all this kind of stuff, because a lot of times that's what slows things down. Things get to 90% done and then people are like, oh, now there's only unfun stuff left. I'm going to go over here, so that could help with that. But what made Drupal 8 takes so long is because of the way releases ran in the past, we would only make big changes in major releases. And so that meant that it caused a few problems. One is you need to do all you can eat buffet when you have this narrow window of time. I think for Drupal 8 it was 18 months or something like that where you can quick clam your stuff in, because if you don't get it in now it's never going to get there till Drupal 9, which might as well be in 25 when there's space cars and stuff. And that actually caused a bunch of problems, not only from a release management point of view when that we're still cleaning up stuff from features that went in two and a half years ago, but also it causes a bunch of interpersonal issues because it really intensifies the arguments about people advocating for their stuff to get in now versus later. So I think the biggest thing that will help with that is not money related at all, although please give us money. We could definitely put it to good use. The stuff that will help with that is the release management stuff. So being really adhering to semantic versioning, not breaking backwards compatibility, but allowing those new features to come in at a predictable six month release cycle. As long as we can make that happen, I think that that is going to quickly both reduce the cost of getting things in. It'll also make it more palatable to businesses to actually put some resources into core development because instead of seeing their new stuff I don't know when, they'll see it within four to six months. Then the big things, the Drupal 9 things, the plan is rather than in Drupal 8 what we did is we basically opened Drupal 8 up for development I think three months after Drupal 7 shipped and really only waited that long because of the Git migration. So instead of opening up Drupal 9 immediately after Drupal 8 ships, we're going to hold off on that until there's a compelling reason to do so. A compelling reason to do so would be that there's enough features actually done in sandboxes or in issues or something that cannot be backported to Drupal 8 in a way that's backwards compatible, that it's like, wow Drupal 9 is going to be a really compelling product so we need to execute on it. And then I think what would happen at that point is we'd have a much shorter feature feature thaw cycle where it'd be these things that are already done plus maybe a couple of other things and we would lock the doors down at that point in ship. So that is the hope that the release management changes we're making as a part of December is going to fix that. Who knows what the future will hold? But we definitely did learn a lot with Drupal 8 that we do not want to preach in the future. I think everybody's on the same board with that. So does that help? I didn't answer your question about money. I'll think about that more and get back to you. Do you have $300 million? Because, okay, yes. So I hope this isn't going off in too much of a tangent, but because you're talking about the change in release cycle, current policy is that if I find a bug in Drupal 7 or God help me in Drupal 6, I post the issue Q, I post a patch, someone says, oh, first we have to fix it in Drupal 8 and then backport your patch to Drupal 7 or 6. So is that policy going to change with the move to the new release cycle and semantic versioning? I don't know anyone who wants, I know a lot of end users who want to change that policy because it's like, why to fix a Drupal 7 bug do I need to learn Drupal 8? That makes no sense, right? The core developers don't want to change that policy because we don't want to end up in a situation where Drupal 8 shifts with regressions and we end up having to fix the same bug twice, right? At the moment, I don't know another way to get people to fix the bugs in Drupal 8 as well other than forcing them to do it through the backport policy. So just do you know more about this than I do if there's changes planned to that policy? I know there's an issue where we're discussing it, but I don't know what is actually happening with that. My understanding though is it's mostly talking more about issue management that we would open two parallel issues but postpone one until the other one is fixed or something like that. Yeah, so what Andy just said is essentially correct. What we might be changing is the way that we manage the issues around the changes since the Drupal 7 fix sometimes in the current release cycle, the Drupal 7 6 might be significantly different technically from the Drupal 8 fix and the discussion might be related. We're talking about whether it might make sense to split those issues up or not, but I don't think that anyone wants to change it so that we would ever make a fix to Drupal 7 without making the fix to Drupal 8 first, or such that we would make a fix in Drupal 8.1 which is under Drupal 8.0 but not make the same fix in Drupal 8.1 that's under development because that would create a lot of extra work for us. So the actual backport policy I'm pretty sure is not going to change. No one wants to change that. Well, lots of people want to change, but no core developers want to change. I don't think that anyone in the release management team wants to see that happen because it will cause more problems for us in the long run. It actually makes more work for us. If we can get good answers to how to address that, we could probably talk about it, but so far people haven't been able to address that. How do we not ship with those regressions in Drupal 8 then? It's a tricky question because the economic incentive for fixing things in the sci-fi, basically cute little R&D project is non-existent versus the thing that people actually need. So it's actually an important driver of those fixes in the future version to tie them to fixing it in the current version. It's a lever that we use. So until we figure out how to not need that lever, we haven't had a good answer to that. One other thing. I would also say that I think with the semver change, it's going to be a lot less of a pain in the butt to back-sport stuff. Drupal 8 right now, some bugs, backporting them to Drupal 8 is like being on a different planet. But I think that I'm hoping that the new release cycle will make it so that it's actually sane to backport changes going forward. We still have the problem between 7.8, obviously, but between minor versions of it, I think that we'll be able to see more, hopefully, more staggered process so that the backports are not awful. Have, sorry, are you hearing me? Have we forked symphony or will updates to symphony be tied into updates to Drupal from now in Drupal 8 moving forward? Yeah, it's a good question. We have not forked symphony, I know of. We subclass a couple of things that we need done a little bit differently. Our routing system is a little bit more demanding than what symphonies does because we provide UIs for turning on functionality, which blows everyone's minds. We've talked a lot about how to handle, not just in symphony, but also in JavaScript libraries and stuff like that, because we don't really want to be in a situation where we're shipping with old, cruffy stuff that no one uses anymore, four years from now. I believe how we would handle that is a couple of different ways. For JavaScript libraries, what we've talked about doing is at these minor releases, so 8.1, 8.2, 8.8, it's understood those are going to have bigger changes in them than the point releases that come out monthly. And so those would be good points for doing at least minor version upgrades of symphony and stuff like that. We would also probably do major version symphony upgrades in there, but there we would have to provide a BC layer. So that would be a situation where we would be subclassing things in order to provide the symphony II version of a symphony III functionality and stuff like that. As much as possible right now, what we're trying to do is set ourselves up so that we're future compatible with symphony III. For example, there's a critical issue which got fixed before my presentation, so it wasn't up there. But to rewrite all of our validation, places where we're using symphony validator in a way that is compatible with symphony 2.5 and symphony III, so we wouldn't have to rewrite that stuff again. But the way we would handle it is the same way we would handle it if we change any of our interfaces or any of our class definitions that we're going to have to provide a BC layer for sites that need it, but then make it really easy to get to the newfangledy stuff for people who want that. And essentially we'd ship with both. And does that make sense and did I lie? I think that is correct. Okay, nobody said I lied, so I think that is what we're doing. So I'm gonna give a marketing tip. So I see the countdown and we're like 28. 26. 26 criticals left. So I think one thing that would sort of help just from an emotional marketing standpoint is to rather than say there's 28 issues, say like 14, 1400 and 68 or something like that out of 1500, no critical issues are done. Right, because it gives people a sense of like dramatically more momentum that's going on and it really reflects the level of effort here comes Jess. You might want to sit closer to the mic, Jess. And then the other thing is like, we had an internal talk about this, but I'll have it in public now. But one of the things that's interesting is like, so we're always acquiring new forms of talent in the Drupal project. Right. And so, you know, one of the things that it makes me think about is like this introduction of 1500 critical bugs in the Drupal 8 release cycle. It's like, how do we fundamentally address that? So, you know, back in Barcelona in 2007, like we got pulled off into the corner and it was like, listen, if you guys are gonna be serious about Drupal and like being in the enterprise, you need to build a testing framework. So we went off and built that. And I was like, yeah, let's write like 4,000 tests and like that'll cover every possible imaginable functional capability that Drupal will ever have. And we're all good, right? So we're like, now we're at like, what, 80,000 functional? 95,000 functional tests, and we still have 1500 criticals. So it's like, how do we come up with like a QA capacity beyond, you know, where like somebody's, somebody has to like sign off on a functional spec to go like, no, for this amount of code that we're introducing, like the probability that we're introducing, like a historical norm of, you know, 25 criticals that we'll discover over time is no longer going to happen, right? Like somebody, you know, some way to address, you know, just There you go. No, it was 300 million. Yes, even better use. So I think Jess is going to talk about the showing the number of criticals. So I'll address your second point first, which is, which is a good one. It's like, why is it that we ended up with all this technical debt, especially given that we have, we do have some safeguards against this, like we have what are called Drupal core gates. And one of them is testing. And we won't commit a patch until it has test coverage and stuff. And it's a good question. Because when you look at the nature of the criticals left, a lot of them are sort of unforeseen problems at the beginning. So even if we had a functional spec, I don't know if it would have caught all of those necessarily. But certainly we do, we do endeavor to make sure we don't commit a new you or a new API like configuration management until we have test coverage of everything that we can think about at that time. Where these things often come in is when configuration manager is sitting around fine and not bugging anybody. And then all of a sudden somebody tried to push this thing into it, which was also fine in isolation. No one thought of it together. And the integration of those two things was what caused critical issues. Any API in views is a good example where views by itself was working fine. Any API was working fine. And then people started to notice like, oh, but because views is doing one thing here and any app is doing something over here, we could actually introduce security problems because a configuration change is not taking effect. All of those got fixed as well before my presentation. It's something to think about. I think it would be good for the risk management team to do some analysis on the critical issues that did come up, those 1500 or whatever that we fixed and try and figure out if there are safeguards we could put in ahead of time. I don't know if we're functional spec is quite the right way to do it, but maybe it is more of an emphasis on writing functional tests versus unit tests. Oh, I don't know. But I feel like, you know, a lot of these things that we're finding now are because people are clicking around the UI and all of a sudden finding things that make no sense versus the unit test weren't catching those things. So it's interesting to see if, you know, different ways that we could do that. And I would invite if anyone has ideas on that, I would love to hear them because nobody wants to be spending, you know, an entire year fixing critical issues. That's not really fun. So yeah, good, good thought-provoking question, Karen. I don't have any great answers. Other than I, just to set your remedies, we do at least try to prevent that from happening by front loading gates in front of people like performance and testing and such. So yes, Jess. I will say also that we actually have been doing the sort of critical source or like the analysis of where the critical issues are coming from that as you described since last summer. And it turns out we actually don't, at least in the past year, we haven't broken that many things compared to the total number of critical issues. Like it's more, it tends to be more a matter of something that was already broken in Drupal 7 needs to be forward-ported to Drupal 8. And right now, as you saw in Angie's presentation, a lot of issues are, you know, significant performance and caching improvements. If we had made those performance improvements, if we had added all of this caching two years ago, that would be premature optimization. And we would have been doing a lot of work twice and in the long term possibly introducing more technical debt. So at least in the past year or so, we're definitely still breaking things. But a lot of the biggest things that we've broken came out of the very last changes that we made before we released the beta. So we decided we made a decision to support a couple of new big things. And when you add new functionality, that's usually the biggest place that you're going to accrue new technical debt to. So it's not like we just weren't paying attention and broke things. We introduced an awesome new system that makes it much easier for the entity field API to maintain its data structure so that developers don't have to always update that manually. That introduced a bunch of new bugs that had to be fixed as a part of that. I just wanted to add that. But with regard to your point about marketing, so one important thing to keep in mind about the number of critical issues is that it's always changing. We're always discovering new problems or deciding that new things need to be fixed. And out of all of them, most of them are actually fixed. Like one in three critical issues are fixed within one week. Like it's not like they're sitting around forever. So those 26 issues that are left, like that's actually the ones that just haven't turned over. So it would be like 1,437 out of 1,470 whatever. And then like in a month it would be like 1,527 out of 1,537. So it's actually, it's an ever-growing thing. So it's not really, I actually do, I did last year make a graph of like the total number of critical issues. But it's kind of hard to keep track of that. Because I can't remember from day to day whether I have to go to, you know, 1,527 to buy. It's also very depressing when you look at the number of critical issues. Like I get what you're saying that it shows like, look at this. Like if you showed a bar graph, right? And there was 1,500 in total and we've got 26 left. That looks really good. The problem is like, you know, like if you show it as like a, as a burn down graph, it's like, oh my God, we're never going to be done. So, you know, it's like, it all is in the presentation of data. But I totally take your point that, yeah, but an emphasis on what all we have accomplished versus only an emphasis on what's left that I think that makes a lot of sense. Yes, I think we have one more question and then I'm pretty sure we need to leave. Okay, so I've been doing a little bit of work porting my Drupal six, Drupal seven modules to Drupal eight. Yeah, sometimes I hit something where I'm not sure if it's an issue with my implementation or if it's an issue with core. So is there a place where I can go without disturbing the people who are busy working on Drupal eight core and ask them, Hey, am I doing something really stupid? Or is this actually a problem in core that needs to be addressed? I see a wild hand over here. Who are you? So, so what is your name? Socket wench, right on. So you should talk to socket wench. No, but I think that is one thing you can do is is collaborate with other module porters. And socket wench has done a bunch of this lately with the flag module. I think generally speaking, if it's a contributed module, just come in and Drupal contribute. I see people asking questions in there all the time, and they're totally fine. If you're trying to help move Drupal eight forward in any way, and it doesn't matter if it's core or contrived, just ask. Is that the IRC group? I'm sorry. Yes, that's the IRC channel. A lot of people are asking Drupal eight questions on stack exchange as well. Drupal stack exchange. Kathy, you look like you have something you'd like to say to that as well. I think one of the patterns that I have seen is like Tess, when she runs into a problem, she'll talk to people, but eventually she'll make a core issue for it. And she'll be like, this is how to reproduce the problem. So I think it's okay to make a core issue. People will look at it and we can talk about it there and have a discussion. And if we decide it's not a problem, we just move it out of the queue or we document why it's not a problem. So I think it's totally okay to be like, look, this is what I tried. I think like maybe it's broken. Don't be afraid to open an issue. It's okay. You're not bothering anybody. We can ignore them. Well, no. And I, but I think, I think, I think it's, this thing is even better than that. We don't want to ignore them because the fact is most people working in core are not porting contributed modules because they don't have time. So getting feedback from the field from people directly trying to do that is insanely valuable. And we can make a call on whether we think that should block release or not, but don't ever be shy to talk to people because we're, we're really nice people. Yeah. So we do it with issues. We do it with IRC. Also come to the sprints and sit with people and have fun. And yeah, and yeah, but don't be, don't be scared. Really, like, yeah, people are generally very understanding and especially if you're working on a contributed module, that's totally Drupal contribute material. Like so. All right. I'd say on that is if you, if you are struggling with knowing how something is supposed to be designed in core, come to the documentation group so that we can make the documentation clear enough so that you don't have the question about whether that's the right implementation to begin with. That's excellent. Thank you. The documentation. All right. So I don't know how to figure out a program schedule. That's probably what I want. I'm pretty sure we're over time. We are. Great. Okay. So thank you everyone for coming and I will see you at the sprints. This is