 So, welcome to Drupal 6 End of Life. What happened? What can we learn for the future core conversation? Hi, I'm David Stopak. I'm a member of the Drupal security team. Also co-founder of My Drop Wizard, which is one of the Drupal 6 long-term support vendors, which will be pertinent to later conversation. I maintainer, co-maintainer of 20-ish projects on Drupal.org, and co-organizer of the Drupal for and for meetup in Milwaukee, Wisconsin. If anyone is ever in the area, please come join us at our meetup. We have the best food at any meetup ever. Our co-organizer makes home-cooked food for every meetup. It's not just like pizza delivery or something. I'm legitimately surprised that people don't show up just for the food. Like, Drupal, yes, let me have another serving. And my most important role, as I am Tata to my two beautiful daughters, I couldn't decide on a picture, because in this one, Sasha's smiling, and in the next one, Ava's smiling, so I had to make an animated gif. Those are fatherhood problems. So straight off the bat, I just wanna say this is a discussion. My goal is to just be a facilitator to that discussion. I'm gonna present for a little bit about what happened and some of the concerns, and feel free to shout out questions or comments at any point, especially since we have a super small group. And then at the end, we'll have an open discussion. So what is end of life in the Drupal context, in case anyone is unfamiliar? Traditionally, Drupal supports only the current major version and the previous version. So right now, that's Drupal 8 and Drupal 7. A new major version usually means that a previous becomes unsupported. In other words, it's end of life. So before Drupal 7 came out, 5 and 6 were supported. When Drupal 7 came out, 5 was unsupported. That was 5's end of life. So what does end of life mean? There's no new releases of an end of life Drupal core, not feature releases, not bug fix releases, not security releases. There's no support from the Drupal security team. Although, yeah, so that means that security issues could be handled in public. Normally, if someone posts a security issue publicly, we unpublish it and move it to the private Drupal security queue. But if it's unsupported, those could happen in public or maybe just never get fixed. What happened with Drupal 6 was a little bit different with regard to the security team. We'll talk about that in a little bit too. And just in general, community focus is elsewhere. I think in the lead up to Drupal 6 being end of life to community focus had already pretty much moved on, but it's official, right? People won't try to, I don't know, give token support to the Drupal 6 version of their modules. So this isn't, Drupal 6 wasn't the first time we end of life a Drupal. Drupal 5 also went through an end of life, which apparently was on January 5th, 2011, the day that Drupal 7.0 was released. Who remembers that? Awesome. Was anyone super concerned at the time about Drupal 5 being end of life? You really, Jens? Oh, cool. I'm, thank you for sharing. Yeah. So it- Did I just ruin your- No, no, no, I'm just, I'm surprised and I'm happy to have that new data. So at the time, like I wasn't thinking about Drupal 5 at all. Like I was just thinking about Drupal 7 and how awesome that was gonna be. Because at the time, I didn't have any Drupal 5 sites left. Like the migration from Drupal 5 to 6 was sufficiently easy. It was like a weekend project. So like, I mean it was still Drupal, right? So it was not, I remember rewriting smoke menus. Well that's great to know. It took a year. It took a year. So if you would have started like the day Drupal 5 was released, you would have had it migrated by the time Drupal 6 was released. There was only a year between Drupal 5 and 6. My joke wasn't good. Yeah, so the Drupal 6 End of Life was a bigger deal. Drupal 6 was supported longer than any previous Drupal version. Drupal 5 was supported from when it was released January 2007 to January 2011. So four years. Drupal 6 was supported from 2008 to 2016. To put that in perspective, like Drupal 7 so far has only been supported six years. There was a much harder upgrade path. I had a Drupal 6 site that I tried literally for years to upgrade to Drupal 7 and I never did it. Before I finished it, like Rackspace lost my VM and the site is gone so that's all that probably. Yeah, it had more sites than any previous End of Life version. So this is the update status or the, I don't even know what you call it, but the statistics from the update module about how many installs there were the week before Drupal 8 was released, or I guess the four weeks before Drupal 8 was released. And so there were 120 something thousand Drupal 6 sites, which isn't super accurate, but I think proportionally it's maybe more accurate that represented about 9% of all Drupal sites. So to sort of get us in the mindset of what people were saying and thinking around the time that Drupal 6 was End of Life, we're gonna look at a couple of comments that people wrote. I'm very disappointed by the handling of version transition by the Drupal community. Not sure it was decided by the community, more certainly by a team of geeks that cannot understand why ordinate people would stick on older versions. The fact is that Drupal is not backward compatible, migrating from DX to DX plus one is the same work as going away from Drupal all together, which is not entirely untrue. I currently run a complex site on Drupal 6 and I've been trying for the last few months to work out how to migrate it to Drupal 7. However, the migration tools available to me are extremely limited and I've been going through the painful process of rewriting all of my custom modules. However, with the impending release of Drupal 8, I've been wondering how soon I'll have to go through this migration pain again. So we're gonna look at a couple more, but before we do, I just wanna give a really quick warning. Some of the comments got really hyperbolic, like kind of unrealistic from the perspective of what they wanted, what magic they wanted the Drupal community to do for them. But please don't laugh. I'm not putting these up here to make fun of people for making crazy demands or whatever. Irregardless of what they said, which was totally in the heat of the moment, the sentiment is honest and the pain they were feeling is honest, so let's respect that. Not only do we need Drupal 6 for eternity, but also PHP version supporting it for eternity. Eternity means our lifetime, our friends and members who populated our sites. Upgrading or paid processes to do so is simply not possible. Someone needs to think of us. And I really like this comment in particular because of the someone needs to think of us. Like the people who were upset about Drupal 6 being end of life, like really identified super strongly with each other, like they were in us. They were a group of people being ignored by the Drupal community. Here's another one. Absolutely, hashtag boycott ending D6 support. It is not an option for all to just simply upgrade to D8. D6 was always a community project I thought. This consume slash upgrade or die mentality is absurd. This one got a ton of support in the comments. Lots of other people said very similar things despite the logical complexity of boycotting the stopping of something. So people were upset. People were really, really feeling the pain of this, which at least unlike my experience of Drupal 5. Some people did experience some pain. And this is even though the community tried to do a couple of things to soften the blow, which we'll talk about now. So the Drupal 6 end of life was slightly more gradual than previous end of lives. The Drupal 5 end of life happened the day Drupal 7 came out. The Drupal 6 end of life was extended three months. So Drupal 8.0.0 was released November 19th, 2015. And then the end of life actually happened on February 24th, 2016. It was the first time that three versions of Drupal were supported at once. And the security team really rallied to get a last Drupal 6 release out for that February 24th. Drupal 6 also experimented with long-term support vendors. So the idea is the security team was no longer going to support Drupal 6. The security team is all volunteer. And rather than them spending the time to do that work, maybe commercial vendors could do it for the people who are still interested. So there was a call for applications to be a long-term support vendor in June of 2014, which I think is even before I, like I personally had heard about this, but I looked at the node on Drupal.org and that is when it was published. And the vendors were ultimately selected in November-ish of 2015. Despite lots of people being really, really upset, a whopping five companies applied in that year and a half time and three were accepted. And those three were Acquia, Tag1, and My Company, My Drupal Wizard. Yeah, it was sending an email to security at Drupal.org. And there was like certain things. Yeah? Can you repeat the question, actually? Oh, what was the submission process for applying to be a long-term support vendor? I think it was, yeah. Any other questions? So what did the Drupal 6 long-term support vendors do? They do very similar work with similar tools to the Drupal security team. I guess with the one exception is that the Drupal security team isn't usually the one to actually write the security patches. The security team's mostly doing coordination and the module maintainers write the security patches. But in this case, the Drupal 6 long-term support vendors are the ones actually creating the patches. Yeah, so Drupal 6 security patches are still worked on on security.drupal.org. And the LTS vendors have access to confidential information about D7 and D8 issues. The idea is that the Drupal security team won't even spend the time to look at a security issue and say, does this affect the D6 version? Like to not even take volunteer time away from that, the LTS vendors will look at any of the incoming issues and make that determination themselves. In exchange for having access to this confidential information, the LTS vendors have agreed to publicly post all of their patches at the same time they give this to their customers. So an LTS vendor can't use that information to just help their customers. They have to contribute back to the community. Vendors collaborate but only on patches that affect their clients. So like if Tag1 and MyDropWizard both have a customer that uses module X will collaborate on creating the security patch for that particular module. But if none of the vendors support a particular module, maybe no security patch will be created. All the vendors are totally different. I don't really know a lot about what Tag1 or AQUIA's offer is if there's someone here who knows what that is from one of those companies. I'd love to hear about it. But just as an example of what our paid long-term support offer is, this is what we do. So MyDropWizard does Drupal support maintenance for a fixed monthly fee. That's all we do. We don't build new sites. We just support maintain existing live sites. Our Drupal 6 long-term support plans are basically exactly the same as our seven and eight ones except we do this security patchwork and they cost 25% more to account for that. Our cheapest LTS plan is $125 a month. I think Tag1 maybe has a cheaper one that I'm not super sure. Yeah, a Quo. But I wish someone from them had come. What's the cost? Oh, okay, so it's actually more expensive. So we'll handle security issues for any of the Drupal 6 modules on your site. If you're just following the publicly posted patches, we might not cover all of your modules. If you want all of your modules covered, you need to sign up with a plan with us on our Acquia and we will actually install the patches the same day that they are released. I think Tag1 just sends the patches to their customers. I've used it. What the Tag1 does is it reports up to, it's kind of like a reverse update status and you look at the status on Tag1's Quo site that your site has pushed up. And then it just notifies you if a module has a patch. And I think you do public patches as well, right? Yeah, so we have a super similar thing to, well, I actually really don't know exactly what the Tag1 does, but we have the MyDropWizard module, which is a replacement for the update module, but ours is free, anyone can use it, even people who aren't customers of ours. But if they are customers of ours, we can give them a secret code to do a similar thing like Tag1 is doing that will notify us of what our customers' modules are. But at minimum, if you have a site that you can't afford to get a long-term support plan from one of the vendors, you could use our module and at least be notified when a public patch is posted. So how have these LTS vendors worked out? We've released 27 patches for 15 modules. I think that's actually out of date. We may have done a couple more patches since I made this slide. And of course, these are also publicly available to anyone who also uses those modules. We haven't done any core releases yet. There has been no D6 get-in, because everything has to be a get-in. But I expect that there probably will be a Drupal 6 core release before we're done doing long-term support. We're probably past our peak of Drupal 6 customers, like there was this wave of people joining and then people have migrated or retired the site or whatever. And so we've been slowly losing our Drupal 6 long-term support customers. But at our peak, we were responsible for 424 sites, which is enough for us to justify doing it, to put the resources into doing that work for Drupal 6. But it's really not that many compared to the need. We saw in the beginning there was the 125,000 sites and we're only helping a couple hundred. And maybe Tag1 and Acquia have 20,000, I don't know. But it seems like it was just a tiny fraction of the original need. Oh, so we haven't announced this publicly yet, but we will extend our Drupal 6 long-term support until 2019. We originally said we're only gonna do it to 2017 because we thought people would join and then upgrade really fast. And then we extended it to 2018 and now we're extending it to 2019 because people really aren't moving on that quickly. So yeah, that's what happened. Now it's discussion time. So I have a couple of questions to sort of frame the discussion, but really we can talk about whatever. And let me just run through them and then people can start going up to the mic. So was it worth extending Drupal 6 support by three months? Did it help the community enough? Did it not help the community enough? Did it strain the security team too much? And should we do that again? Were the D6 LTS vendors effective in filling the support void that the community wanted filled? Should we do that again? What else can we do to handle the Drupal 7 end of life better? Because who knows when that'll be? There's talk of waiting until Drupal 10 to end of life, Drupal 7. That link is to an issue talking about that. Jess doesn't want to. We'll get that officially on the recording. And you do I. But yeah, whenever it happens, I mean it's probably gonna hurt harder than the Drupal 6 end of life. So what can we do to try and soften that more? And of course, any other questions or concerns that you may have about Drupal 6? I have a thought. So one, there is a, obviously the Drupal 8 release managers care about this problem a little. There is a paradigm shift that I think that we can do with the changes that we've made to the Drupal 8 to Drupal 9 upgraded and what that means, which is that we can take two factors into consideration when we decide when to do Drupal 9. Those two factors are when is, well, they're okay, three, when is there too much deprecated code and core for us to maintain? How many of the 1.1 million Drupal 7 sites are still on Drupal 7? And then question three is, I forget what question three was, but I think that we can decide when we release Drupal 9 and all Drupal 9 is doing is removing backwards compatibility layers from Drupal 8. So that releasing Drupal 9 doesn't solve the problem of when descending to Drupal 7 support, but I don't think that we need to say until Drupal 10 because we don't need to say we're gonna wait until Drupal 10 is there. We can control when the Drupal 7 end of life date is. It could be during the Drupal 8 cycle. It could be during the Drupal 9 cycle. That, I mean, I think that the most important thing is can 1.1 million Drupal 7 sites get off of Drupal 7 and when we're in a position where we enough of the sites that are on Drupal 7 have like when that starts to go down and maybe we have an indication that we will see what happens, right? But it doesn't have to be tied to a major version release date any more ever again in the future ever. Right? Yeah, I think that's really. That's my thoughts. Thank you. I want to give another point of view which isn't from my point of view. It's not that people get off Drupal 7, right? Because I might have an application that does exactly what a customer wants and doesn't need to upgrade, but we have to provide security for it. So when my customer understands Drupal 7 is end of life and I can provide security through them either through long-term support or through my own development team, it shouldn't, I guess it matters to the community when you end of life but when as a business owner and to my end customer the end of life only matters so much as I can provide a secure environment to run that application. So one of the things that I wanted to bring up was I thought that the long-term support really provided a great value to people like us that needed to, you know, there's no ROI on upgrading a site to do the exact same thing that it's doing now. And it gave us a way to continue providing a service to those customers who needed them. So I'm not saying there's anything bad about the LTS vendors. I mean, I didn't say anything about the LTS vendors. I'm the Drupal 8 Release Manager or one of three of them. So I'm just speaking to the very first thing on there which is who knows when it'll be? There's been talk about waiting Drupal 10. That's the only point to which I was speaking. I think that's a really interesting idea though to not tying it to any other release because it is like kind of abrupt to say like, okay, this release is out and also it means this other really huge thing. Yeah, why not separate the huge things? Yeah, so I have a company that's on Drupal 6 and I'm like, I don't want to upgrade at all because it's like seven years of custom code. I was one of those people that used it as like a custom application framework so there's like no migration path to anything else. And I guess for me it was, there is a group of people like me out there and I guess I was a little surprised. It's like why not rally at least that niche group of individuals to rise up and become the core security team of Drupal 6 and continue to support them because they're the ones interested. They don't have to take, they don't have to always be focused on Drupal 7 or 8 but if there is a supply of individuals because I'm a developer as well it's like that can do those patchings and all those things like that. So I just never heard of any talk of that at all. Are there anybody, or is there anybody interested in doing that security for Drupal 6 and if there were like, could that be part of the security team? That's an interesting idea. I mean, I think just having the LTS plan with the vendors like kind of maybe prevented that from sort of fomenting, right? Because you know, there's these vendors who are ready to do this and then the community is saying they're gonna do it and they're wondering why are we doing something that other people are getting paid to do. I mean, I don't know. It's like a sub community within a community, which is. Yeah, so the- Can I go talk to him? I don't know. So, I'm gonna sit down. The answer to that is it's a lot cheaper to pay a MyDropWizard and Aquia, a tag one, oh, come on, to $150, am I quoting that correctly? We're 125, I guess. I'm sorry, $125 a month than to spend development time on it. The issue with this is that there's a huge level of trust involved. So, one of the things that we as the security team wanted to be careful of is that we're not giving folks that are really only interested in supporting their own infrastructure and their own sites and access to all of the issues related to Drupal Core for six, seven and eight, which might include six. So, all of these vendors are also, shouldn't say all of them because that's not actually a true statement anymore, but most of these vendors, and I'm looking at David as calling him a vendor, but he's also a human being. Hi, David. Also participate actively on six and seven issues. And while you may be supporting Drupal Six Code, you are also writing patches for Drupal Eight. Like, yeah, so, I don't think that's a feasible thing just because the circle of trust is somewhat narrow here. Having said that, if you want to apply to join the security team, then you can support Drupal Six, seven and eight. I think those are valid concerns with regard to giving people access to the confidential information for sure. But I think if maybe there were no vendors, that maybe a community effort could have tried to make those patches after the D7 or D8 ones were released. If you want to take, I think there are people out there. I think there are people out there who are grabbing the patches that are released for D7 and D8 and making backports for Drupal Six that aren't on a vendor and just need it fixed. That's definitely happening and they're not posting it. The whole point of the LTS vendors were to centralize this in one location so that people could basically get a free ride off of your paid clients. The question we had was this ever gonna be worth it for an LTS vendor to provide the service and it sounds like, yeah, it is, was, because you're extending this for another year. And when Drupal Seven comes out, if we follow the same model, which we don't know if we will yet, but if we do, then you'll have significantly more customers, it sounds like, because there's more customers on the end of life. But yeah, that's kind of where that is. Certainly from a selfish perspective, I mean, it would be good to have more LTS customers on Drupal Seven, but I guess the question is, is that the best approach for the community, for the health of Drupal as a whole? And I don't have the answer to that and maybe none of us do, but that's the question I'm posing. I mean, there's... Just leave it off the... I don't want this to turn into David and Michael having a conversation when you've got this line here, but there's the sad fact that Drupal Six wasn't being marked unsupported. I don't think that what you just said was a method. It's not, well, it might be to some. I mean, it took us going to the Drupal Eight maintainers and saying, hey, before you guys can release Drupal Eight, you are gonna stop working on Drupal Eight, you're gonna come back and fix these known issues in Drupal Six, so we can have one last Drupal Six release. And so, and it was really funny because you could see the internal discussions of these people who had been working on a nice, awesome, modern code and then having to go back and say, oh, wait, we can't use that library. We can't use that function because it didn't exist in the PHP version that Drupal Six supported. So, I think one of the problems we have here, and I'm gonna shut up as soon as I say this point, is helping developers not use, not build so much technical debt in their site so that it's not impossible to upgrade, which Drupal Eight has done an awesome job of doing it. Okay, I'm done talking, so sit down and bury my head. Thank you, Michael. Thank you for your comment, not thank you for burying your head. Thank you for showing up. No, thank you for your comment. Hi. Hi. Wow. I hate microphones. Maybe that's why it should be. Okay, I'm Mike. I apologize if I also hijacked the conversation to some degree. It's sort of a somewhat different direction, but there are some things that I'm really interested in that are related, the sort of supported vendors that are commercial that work with the security team is a very interesting idea to me from a, can we use the same model to back port security fixes? Like, let's say somebody builds a site now on 7.54, that's probably still happening. They hire an agency to do that. They're not going to update the site ever again unless they keep paying the agency, right? So, your choices are get an upgrade that might, or an update that also has other stuff that you don't want because your site's done and it does what you want, and it might break, but you're secure, or you're not secure, right? Because you don't know how to build a site, you're not a developer, you are a restaurant or whatever. It seems to me like, and maybe this has already been talked about and it's been decided that it's a bad idea, but it seems to me like this model of vendors that have access to the security information would be even more applicable for back porting within a major release. Has that been? So, what you're proposing is people who will back port like security fixes on the Drupal 7 branch so that they don't have to upgrade to a later Drupal 7? Yeah, so like then 7.55 comes out and a vendor figures out what, well, hopefully has access to the security information, so it doesn't have to figure anything out. They just back port it and make sure that it works, right, and usually a pretty easy automated almost process to do probably, but. And you're talking about back porting to a different D7? I think that supplies even more in the D8 world when like each D8 point release, like they're theoretically backwards compatible, but they're also, as soon as one's released, the previous one is insecure. And I've found that everyone has had right broken something, small usually, which is great, it's much better than like going from 7 to 8 for sure, but it's still, you know, it happens and maybe having somebody back port to like 8.2 might be useful. Okay, so the Drupal 8. Is that a similar? Yeah, that's exactly, I mean I used 7 as an example, but very much so you're right, I think it applies in 8 and will apply more in 8 as there's more sites in 8. So just to make sure that I understand, it's about making like patch releases for older versions so you don't have to go to newer like feature releases. Yes. Okay, interesting. Because of this idea that I think most people, once the site is built, adding more stuff to the site does not add value to their business or their mission with their site, right? It's like it's done. So, yeah, I was wondering if that's something that anyone has, please. I was just saying for whatever it's worth, we do that in the Magento world when we release a security patch for one, we go down the others that are still actively maintained. So. With an open source or? I think you have it as well. I think the patch file. I may have misunderstood what you were saying, but we release the patch file as well. So I think if there's a business case there, then we plan this idea in some heads, then it will happen if it makes money for people, but it will be, I don't think the open source community has the resources, that's why we decided to, that's one of the reasons we decided to drop support for older, minor versions, because we don't have the resources to like back port everything and ensure that it actually works and it actually secure and is not breaking anything else there and et cetera, et cetera. So we don't have the resources to do that, especially as the more and more minor versions get passed behind us, but if there's a business case for that and we want to set up an LTS like system or if there's some company that wants to make money out of this service, then sure, why not? It's open source, anybody can do it. Well, because there's, it doesn't require access to the confidential information. I mean, it's basically a rebase which you could automate. I mean, so yeah, you pretty much could do that now and my only point is, could you get it one step better so that like the vendor has the release for the older version at the same exact moment that it drops for the leading edge, right? And I think you could maybe even do that now if someone from your team, if the person from your team who would be doing this work joined the security team, so long as they don't release it before the security team releases the official version. Or market-based information for company gain. But it's public as soon as the official release gets published, and so as long as you publish it a second later, right, it should be, which just as an aside, like join the security team, please, pretty please, the security team is a group of volunteers that is remarkably small for the scope of its task, right? It's like 40-something people, 39, and at any given time maybe 50% of those are active and the security team's responsible for coordinating Drupal Core security releases, security releases for all of the supported contrib modules which is in the thousands or tens of thousands, I don't know how many now that we're very clearly delineating. So yeah, if anyone has the skills or the interest and the get vetted role. Yes, talk to Michael, okay. I'll finish up quick because the line's getting longer. Yeah, the other reason that I brought it up is so I'm also working pretty extensively on trying to make core updates in browser a thing that you can do, because that's also a feature that you would need just from a purely getting the technology out of the way standpoint. If you are like a restaurant that just needs to keep their stupid site up to date, right? Like WordPress can do it, we should be able to do it. But once that's there, I really wanna be able to also say yeah, and you can update just the security stuff, not the new features and the model I've always thought of would be to have vendors that produce those. Anyways, that's where I'm at, thanks. Thank you. Hi, I'm Dave. I think one of the problems, at least from my perspective that the Drupal 6 end of life had was the abruptness of it that it went from the day before Drupal 8 was released, Drupal 6 was still on the D.OS site and you were still sort of tacitly encouraged to go build a website in Drupal 6. And then like three months later, it was end of life and your option was to either upgrade to Drupal 7, which is difficult, or use an not entirely supported upgrade path to Drupal 8, which I mean I've contributed to, but it still, that means I know that it doesn't work in some cases. There were major features that don't work in a lot of cases. And that's like an honestly really difficult thing to ask people to do. I'm wondering maybe for Drupal 7, I'm not saying there was a mistake to do it that way. It was just the way it had to be, because we kept supporting it for such a very long time and it was just time for it to drop. But for Drupal 7, maybe we could do it in a more stage way, where one day we stop saying on Drupal.org, build your site in Drupal 7. Way before we end security support for it. We just say like we don't think you should do this anymore. And then another day we say, modules that haven't been updated in three years are no longer security supported or something like that. And then another day we drop core security support and then maybe like several years after that we drop upgrade support even, because there's no way that Drupal 12 is gonna have an upgrade path from like six, seven, eight, nine, 10, 11, right? And so having some kind of staging process, but more importantly a plan so people know ahead of time when Drupal 10 is released, then stop building sites in Drupal 7 or something like that, it might. Debateably we could even do that now. We could tell people don't build new sites in Drupal 7. So sorry, this was part of what I was trying to get at with my comment before and I probably said things that were too like in world for people who pay attention to release schedules, but the difference is schedules. Like we have schedules now, we like Drupal 8 was released quote, when it's ready. And what I was trying to get at is that for Drupal 9 and for the end of life day of Drupal 7, we have changed things so that we have the option of setting a schedule. So I think that's exactly what we need to do. And we will. So I would like to bring in something that was talked about but not so much maybe, migrations. So as you've had a call for people to join the security team, I would add a call to join the migration team because I think when we've added the migration system, there was a lot of hope that the migration path would emerge magically from clients and sites that need the migration path and they would like magically come together and build the migrations and it would happen organically and it does not, it's not happening organically. There was some people coming in but it's mostly the same very small tight group working on migrations and like tackling all kinds of random issues. So if we can figure out a way to speed that up and expand that would help a lot with even migrating Drupal 6 sites to newer versions and then the Drupal 7 obviously also same problem. So we need a lot more effort there to be able to say that there's a possibility for the 1 million Drupal 7 sites to get out of their Drupal 7 nests. Thank you. That was definitely one of the main sort of threads when the Drupal 6 end of life was coming up. You know the end of life is here but you don't even have a migration path for us. Yeah. I don't know, do we have any data on how many people are updating with which migration paths? Like whether, cause there are definitely some people using like migrate UI, not too many of them as far as I've seen. There are people who are migrating by building custom migrations and these people are just building new sites and kicking the old one like off somewhere. Do we have any idea what people are actually doing? I don't know if there's any proper data. I can say anecdotally that our customers who were Drupal 6 long-term support customers and then weren't, we would ask them of course. And the main thing that happened was them switching to not Drupal. I would say it was probably like 30% Drupal 7 upgrades and then 70% doing something else. Ooh, and that leaves zero Drupal 8, so that's not good. You said 37? Well, in our experience. Yeah, I know that. I don't know how it would look if we had proper data. So I guess two thoughts to add color to that point. So the fact, one fact is that we made a deliberate choice to release Drupal 8 without migration paths being supported yet. We ripped major version updates in place database table migration out and didn't look back two years before we released Drupal 8. We made a deliberate decision to release Drupal 8 before the migrations were actually stable in order. And so like we said, when you first release a bleeding-edged new major version, the main audience are new sites. People who really want new functionality and then I think we thought that the migration path as Gavar was indicating from Drupal 6 to Drupal 8 would be done for, because that's not actually something that we had before like before. You were the official way to go from one major to the next to the next was you actually had to go from Drupal 5 to Drupal 6 to Drupal 7 and in Drupal 8 by using migrate instead of this in place database match by Gascam method. The hope was that we would give people the option if they did want to stay in Drupal 2, migrate their data directly from one to the other and then it would just be a matter of updating their code to the correct APIs for all of their custom stuff, which is the other part of things. So that's one thing is that like it was on purpose and I don't think that we thought it would be 18 months out from the release date of Drupal 8 before like we said the Drupal 6 migration path was done, but it was a deliberate decision and so I guess like we could hope that once we, I mean we can test, we will find out once the migration path is stable whether that will pick up. The other thing though is if you look at the usage data but for Drupal 8 and Drupal 6, there is kind of a like the Drupal 6 line goes down and the Drupal 8 line goes up, but we don't actually know if those are all brand new Drupal 8 sites. I guess like poll if you actually build sites for clients, which I don't do. Like if you have Drupal 8 sites, are they new sites? Are there any customers that you have that are returning customers that are trying to go from Drupal 6, a lot of them are probably just leaving because it's too much, but. So we actually have about four clients which are going from six to eight and we are using migration paths. They're all custom migrations. We're not using the built in Drupal migration path because it was deemed very quickly on in a lot of these projects that they had a lot of cruft and they wanted to start over anyways. And it was a lot easier to actually pick out and extract the content from those sites and then move them into Drupal 8 and then build a new site around that. The migration work we did for one of our clients in the animal humane society took about only four days. Wow. Either that or I drink a lot of coffee and I write migrations very quickly. I tried doing the same thing with my own site it took me about 16 hours. Maybe I'm a little too fast with this. So this is just the migration component though. This is just the migration. The vast majority of it is building a completely new site with new functionality and AHS's site is rather complicated because it has user submissions for lost and found pets and integration with a third party service for stray animals and adoptables with solar integration. It's a very complicated site but the migration was a very small part of it. And so you're doing like you have a script that does like SQL select and SQL insert? It's a lot more complicated than that. For the just the migrations themselves are either a Drupal to Drupal migration using Migrate Plus. The ones that integrate with a third party service are actually through a JSON plugin. So we write a custom data source for that to actually run that as a migration now. It was before a cron job that ran and it ran just SQL queries. It was a mess and now it's a lot nicer. So you are using the migrate stuff in Drupal? We have been for like a month now. Sorry, I misinterpreted what you said earlier. I think using the migrating guide versus the core migration. Okay, okay. Sorry. So just clarified that using the migrate API, the migrate code but not the core migrations that like built-in default YAML files for yeah. Okay, cool, I understand now. On your migration, just to clarify, was this just saying content model you're migrating to very little alterations? I've spent three months on a migration full-time, so it's... Everyone will be Tess's best friend at the end of this. I really hope that doesn't happen. I'm a terrible person. It took, so most of the content that we migrated, there was probably what 5,000 nodes more or less, but the vast majority of this particular site's content is relatively ephemeral because reports on paths and adoption reports only last for so long in the site, but we still need to maintain a migration path. It just, it didn't seem that hard to me. Maybe I'm weird. So I'm thinking back upon the discussion and the presentation and some of the suggestions that I heard about like the community, the Drupal 6 security team and doing some like within versions, back porting and stuff like that. And I just, you may have gotten this, but I wanna repeat it because I think it's important, is one of the things that blocks that is not that there aren't enough volunteers just to kind of take that over, but in order for those volunteers to do that properly, they would need to have access to all of the security issues coming in for all of the versions, which essentially means joining the security team. So I just, I guess I wanted to clarify and repeat that and say that you don't have to just talk to Michael to join the security team. But there's a, there's a, there's a, but so there are a couple of us in the room. So if you're on the security team, then you can raise your hand. So if you want, so like if you have questions about, you know, the security team or how that works in the process and stuff, there's actually like a ton of people you can ask about. And yeah, so I think it's kind of, it's kind of complicated because of the amount of information that affects a lot of other things. It's not just like, hey, I wanna do that. It's like, hey, I wanna have, I wanna be trusted to have access to everything. I don't wanna block people. Do you think it's possible to have a kind of like second tier security? Not that I'm necessarily advocating for this, but like maybe you could have people who like post release of the official patch. Like I know it's not the best to do it that way, but it might be better than dropping support altogether for them. You could have a second tier team that once the official patches have been released and we expect- And then everyone in the world, right? Yeah, well that's the world. Right, but then, but you could have a, you could let people volunteer to be part of the team that does that instead of just saying, no, that team can't exist. All right, so. I think we just need someone to lead that team. Yeah, so it seems like that would be a group on groups.drupal.org or something. If you're trying to do an activity together with a bunch of people based upon, no, I didn't mean it like that. If you're trying to get a bunch of people together, to build a team, and you only wanna do it based upon public information with, and it's clear to all of those people that that's the data that they'll have to work with and that the repercussions are that those things get released after they're public. Right, because the problem with, like let's think of an example. Let's say there's a security release for a Drupal 7, right? And we have this informal team that isn't on the security team. So that release of Drupal 7 comes out. The group starts working on it right away to try and backport it publicly to six. While that work is going on, the vulnerability can be exploited. And so the people who are trying to do that work and wanna benefit from it really just need to understand the implications. It doesn't mean that it's not worth doing that. It means that it's really difficult to explain to customers or people that you work with the implications of that. And a small clarification to Kathy's clarification is that when we do security advisories, we don't release proof of concepts for how to exploit something. Like, you can look in the Git log and see what the diff is. In some cases, we might not release very much information at all if we're concerned about something being exploited very quickly. So the private security issue for full members of the security team will include all of the information that's available so that we can make sure that we're providing as complete and secure a fix as possible and that all of the information going out is as accurate as we can make possible, which requires a lot of trust because it's information that in the wild can result in sites that haven't had a chance to be updated, you know, being owned. So that's one of the other things there. But if you don't need to, if you're less concerned about testing, there is like an intermediate level that's possible. It's just like, okay, I see what this fix is. I'm gonna try to be responsible and not discuss in public how to exploit what I think the vulnerability is based on this fix in the essay text. But I see the change that's being made to this version. And I know that in this previous version, the API was like this. And so based on that, this might be a patch for it, right? Like, it could, I mean, I don't know. I think that you're now creating this, we've just decided like, because you proposed this idea, it's now like your, it's your initiative. No, I was joking because I was addressing it to him as I was saying, right? I think that it is something that, if it is something that's beneficial, then it can be done with public information, we can. I'm gonna stop talking because I just cut in line in front of you. I guess I just have two points, which I know I just don't know what they are. Hold on. Right, so the first one was, it was brought up that there's, it is a substantial process to get on the security team and ask for all that information. This makes a lot of sense. I'm just wondering how that worked for the LTS vendors. Like, was it like, well, they pretty much already are on the security team anyway. So it was fine. Or was it like, how did that work? Yeah, so it actually just kind of worked out that the three that were gonna get accepted already had employees on the security team, which was good. Otherwise, I don't know what we would have done, honestly. So for the record, I'm gonna go into a little bit more detail there just because this is being recorded. So the LTS vendors were evaluated by security team members that were not applying to be LTS vendors and did not compete with anybody offering to be an LTS vendor. So a company that was a, I'm gonna name names. If ACO was gonna apply to be an LTS vendor, then Pantheon couldn't say, I don't think they should be one. So it was a very small subset of the security team that went through and read all the LTS vendors. They had to have experience, strong experience working in core. So they had to have a demonstrated track record of fixing core releases. And that was give us a list of issues you've worked on in core. There was, there's a whole, there's a note on Drupal.org that has this whole process. They had to describe how they were gonna handle this. They had to agree to a bunch of policies. And of the five, I think there actually may have been six, but of the five that applied, of the three that were accepted, it all just so happened that they would have been on the security team. They already were on the security team, which frankly made life easy. We did have a mechanism in place to add the LTS vendors. There's a hidden checkbox on there that adds the LTS vendors to core issues that we never had to unhide. And I think it got removed from the code because we didn't need it. But that was how we were gonna handle that. Something else I wanted to say really quick. Joining the security team isn't that hard. So like becoming a full member of the security team is a bunch of work because there's a provisional member process. But applying for the security team, is it a lot of work? It's answering like five questions in an email. Do you now or have you ever been a member of the... What's that? The... Do you now or have you ever been a member of the anonymous or whatever? I just don't want people to be turned off that they're gonna have to put all of this up front work before they're even considered or something like that. It's things like show us... We ask for examples of your public work in fixing security issues. We require that you have what used to be called get vetted user. We ask you what your... Oh, good. We ask you what your favorite vulnerability is. If you don't have an answer to that, there's a problem. And by that, I mean you have to name a vulnerability that exists on the web. I'm trying to figure out what the other ones are. There was a time commitment. There's a state what your time commitment is per week that you're willing to apply to the policy. There's a disclosure policy that we have. I think there's one other question. Security.drupal.org forward slash join or Google join the Drupal security team and it'll take you to the same place. So the answer... No. The answer is... If you can't point to a list of public issues you've worked on to increase security, then please create a bunch of public issues that fix security and then point to them, which may be a lot of work if you haven't done it. Having said that, if you have extremely explicit domain knowledge in a particular area that you might think may be helpful to the security team, let us know that and just indicate that you don't have maybe domain knowledge and you don't have wide Drupal experience, but you've done a bunch of, you know, JavaScript expert or, for example, or that you understand encryption protocols really well but have never worked in Drupal. So if we're having issues with hashing or something, you know, we may add you to an issue. I've got a list of people who have, you know, domain expertise that we sometimes add to issues when we're all scratching our head like, well, I think that's good. Thanks and then quite a while ago I said I had two points. The other one is just really brief. So I am working on this thing to try to do core updates in browser. I imagine pulling that off would also raise a lot of security questions and so I would love to talk to any people that I could, you know, get that out in the open more with and bounce some ideas off of or see their thoughts or what have you. Thanks. Yeah, definitely feel free to talk to. Yeah, that was the other thing. I suppose to on a semi-regular basis but there's like a hundred followers so I try not to shoot one. Thank you. Mike Paynton on Drupal.org, it's M-B-A-Y-N-T-O-N. Thank you. Is everyone ready for a nap? Oh, there's some administrative random things too. Sprints, which is a great time to talk with the security team about any interesting security Drupal related ideas that you may have. So please come to Sprints and I think the survey is about the whole event and then you can evaluate my session. It was a link off the schedule. Was there another, can I get a new hat? I lost mine somewhere. I've looked everywhere, I've looked everywhere. I think I might have lost it at Nice Camp.