This is a transcript. For the full video, see The story of Drupal 9's release from the inside with the Drupal Association - Tag1 TeamTalk #018.
Preston So: [00:00:00] Hello, and welcome to a very special edition of our Tag1 TeamTalk show. This is our second in a series about the Drupal Association and our series Sharing Space with the Drupal Association's Engineering Team. Today's a really big day for both of our organizations Tag1 and the Drupal Association.
After four and a half years of hard work and development, Drupal 9 was just released recently. And in today's episode, we are going to cover and really, really shine a light on the Drupal Association's, critical role in supporting the build and the release of new versions of one of the most important and largest open source projects in the world.
We're also going to cover what we're going to be doing in the future of Drupal and exactly where we're headed from here in terms of Drupal's roadmap. I'm Preston So, I'm the moderator of a Tag1 TeamTalks and I'm the host and editor in chief of this series. I'm joined today by a very, very, cherished guest of ours.
Today. We've got Tim Lehnen joining us from Portland, Oregon, CTO of the Drupal Association. Neil Drumm, with me in spirit here in New York City. We're not in the same room, but we are relatively close to each other. Senior technologist at the Drupal Association and Drupal 5 core committer. Neil, by the way, was responsible for really defining the core committer role in the Drupal ecosystem.
So thanks for joining us Neil. And we're also joined today by Narayan Newton also based in Portland, Chief Technology Officer at Tag1, as well as Michael Meyers. Who's located currently in the Berkshires, Massachusetts managing director at Tag1. I'm looking at here in New York City and it's a real pleasure to have you all here today.
So, just as a first question, You know, I think everyone's really, really interested in Drupal 9, but let's take a little bit of a closer look at everyone who made it possible. What is exactly the Drupal Association's role in creating and fostering and releasing , this, new major version of Drupal.
Tim Lehnen: [00:01:46] Yeah. I think there's, there's a lot to say here because, you know, being one of these largest open source projects in the world that Drupal is created by the whole community and the Drupal Association job is to foster that effort and support it to build the tools that let the community build Drupal, as we always say.
So, you know, in our case, that means maintaining things we've talked about on this podcast before, Drupal CI and the drupal.org issue queues, the GitLab code hosting itself, the way that we package and release a new versions of Drupal, and various other tools that are used to support it. But then Drupal itself is built by.
in this case, I think there is something like 5,200 contributors who were credited, in the process that led up to the release of, Drupal 9, all over the, from 8.0, all over the last four and a half years for different features that got in. and then the whole core maintainer team, which has representatives from a variety of organizations, who help, Move forward specific initiatives and choose what, has met the quality standards to actually make it into core.
So, you know, they're really responsible for, for building the software itself, but we're thrilled to be a part of that story and to support that effort and, and make it work. And, you know, there's, there's always new things that have to happen for every new major version, so.
Preston So: [00:03:03] Absolutely. And I understand as well that, you know, one of the things that I think people often forget about, the Drupal Association is obviously, there are very, very, important force behind Drupal behind, all of the foundations of Drupal.
And I understand that, Neil, you worked on some of these services that were required to be updated for Drupal 9. These are really, really important and key components of the Drupal ecosystem. Can you tell us a little bit about some of the things that, some of these services that you needed to update?
Neil Drumm: [00:03:31] yeah, so some were more routine like a Drupal CI, adding new environments for, you know, versions of databases and PHP to support, the, packaging pipeline that was rebuilt, for, Drupal 8.8, our, my coworker Ryan, headed that up and what the packaging pipeline is, is what generates the tar balls, which, you download, if you download Drupal, including producing composer underneath it's downloading, downloading those as well.
That added a lot of extra composer support for core, in 8.8. So that was really the point where we moved from Drupal sometimes using Composer to actually supporting co composer is that first cost as in for installing core. And a lot of what I did was around semantic versioning for contributed modules.
so in the past, contributed modules were 7X-whatever, 8X-whatever they had an API compatibility prefix. But now that contrib modules could be compatible with 8 and 9 and 10 11, into the future, that prefix just doesn't make sense. So, it was time to, Take that off and at the same time add that, patch level version number and use some for, so going through our code base, throughout packaging, localization, and you know, everywhere that version numbers might be and auditing, to see, what needed to be updated.
Cause we had little bits of code parsing that was all over the place.
On the core side of that core uses the version numbers too. So Ted Bowman put in a lot of work for getting core to actually be able to handle, semantic versioning in contrib.
Narayan Newton: [00:05:23] Neil, semantic versioning. Did that come into Drupal 9 because this is the point where eight and nine are both going to have to be supported by contrib. And that's the point where it doesn't make sense to not have it.
Neil Drumm: [00:05:35] Yep. Yeah. Yeah. We didn't want to, we
Narayan Newton: [00:05:37] I actually never quite got that.
Neil Drumm: [00:05:40] Yeah. Yeah. We didn't want people to start making a 9X-whatever releases, because really everything, any module you make right now, probably it's going to be compatible with both, Drupal eight and nine.
Preston So: [00:05:56] I've got a question for you, Neil, about that and forgive my ignorance on this because you know, it's been a long time since I've upgraded a module from version to version, but, does the new semantic versioning system in Drupal mean that, for example, you know, we had that recent wave of updates to modules that just needed that single number changed in that .info.yml file.
Does semantic versioning change the need for that, or how does that evolve? How we handle, let's say how modules are registered in drupal.org.
Neil Drumm: [00:06:23] I don't know if it makes any, yeah, it gets module authors, more options for making patch releases and, major releases. And, you know, they can do the whole schedule like core does and support, you know, two or three branches at once, or they can do more simply keep releasing in a straight line, but.
Have more options to communicate. How big of an update each release is. And, yeah, if they you'll still be using some 8X- whatever modules, with 9, since 9 does support the Drupal 8 modules and it's not really need to move to semantic versioning until you're releasing a new major version.
Preston So: [00:07:09] Wonderful. Well, I know that semantic versioning was a colossal amount of work. Obviously you have a lot of different pieces of juggle, a lot of moving parts, so a props to everyone on the team for that. And I also understand that you needed to update the drupal.org API. Is that correct too?
Neil Drumm: [00:07:24] That is probably api.drupal.org.
So routinely, just every six months. We add a new version of core to be parsed by api.drupal.org.
Tim Lehnen: [00:07:36] Yeah, a big part of the, the API sub-site, which, which itself for those who are listening, who might not know, actually parses out the like, Doc Block style documentation within the code base of drupal.org and provides, API documentation, making sure that that supports the next major version.
And every six months release version is really important. And similarly that's effectively a, you know, a documentation site and there's also the community govern documentation on drupal.org as well, which is another area that's gotten some major updates because we're in this new situation where Drupal is becoming an evergreen piece of software.
So it doesn't make sense to have. A separate, you know, having a separate Drupal 7 documentation where the architecture is so different. Totally makes sense. But having completely duplicated documentation for Drupal 8 and Drupal 9 really doesn't make sense anymore. So we've actually begun the process of merging that together and providing version specific call-outs so that where there are distinctions that are important, we can do that, but we don't have two copies of every, every way of doing things when they're fundamentally architecturally similar.
Preston So: [00:08:46] Well, as someone who routinely goes to API.drupal.org, I can definitely attest to just how useful and rich, that site is and just the amount of maintenance it must take. And the amount of thinking that must go into it is pretty significant. so I want to switch to a different topic now and kind of learn a little bit about the future of what's coming in Drupal nine.
I think we've touched on this topic. In a previous episode, but, out of curiosity, you know, is the Drupal Association involved in setting, the Drupal roadmap? Do you all define the next product milestones for the Drupal roadmap? What's the involvement of the DA look like here?
Tim Lehnen: [00:09:20] Yeah. This is another really interesting question.
And it's something that's evolved a little bit over the years. I'll keep it brief. Cause we have talked about it somewhat before, but you know, we don't historically the Drupal Association has not been involved in setting the roadmap really at all. if we go back to the founding of the DA, but, over the over recent years as drupal.org services, like the update service, the localization service, the composer facade, all of these other elements really become part of Drupal, the product.
Then drupal.org becomes part of Drupal. And so the DA has increasingly been, become involved in the discussion about roadmap and the discussion about initiatives. So we meet with core on a monthly basis just to make sure that we're on the same page about supporting each other with what's going on. And more recently we've been involved in, leading and proposing some initiatives for core ourselves.
And that's how the. First phase of the automatic updates work that we talked about in the previous episode started, and a number of other things that have been going on in the background. So, moving forward, that's going to continue to be true. We've already begun some discussion about some possible, additional initiatives for Drupal 9's life cycle.
And those might be things like, well, they almost certainly will include the next generation of auto updates work. Perhaps some work to add telemetry to Drupal so that we can learn more about how it's being used and share that with maintainers. And so it's a collaborative effort. It's still primarily led by the core maintainer team, the sort of open source volunteers who, who really lead those initiatives, but we're becoming more and more involved.
Preston So: [00:10:55] That's amazing to hear. And I think, you know, one of the things I'm curious about though, is that. You know, I think a lot of what we hear about from the Drupal Association revolves around the underlying technology and shepherding the project. And, you know, holding these events, but, but you know, from what I understand, you do a lot more than just technology and engineering.
And some of the things like Drupalcon there's a lot more that goes into the Drupal Association's work.
Tim Lehnen: [00:11:19] Yeah. I mean, it's, it's, I think it's reflected in the Drupal projects, culture of what contribution means, right. contribution isn't just code and, in the same way, that contribution is not just code the work of the Association and the work of the project is not just technical work.
So there's a lot that we do that's about fostering community in various ways about creating space, to build community, whether that's virtual space or space at conferences and things like that. And also just the, the, the whole side of promoting Drupal to the world and marketing it to the world.
it's very easy for us to talk to each other. We have such a big community that we could spend all our energy just I'm just preaching to the choir as it were, but it's of course important for us to evangelize Drupal, and to tell everyone out there. What's new, why they should revisit it if it's been awhile, since I've taken a look.
So that's always a big part of the work we do as well. And you know, we're a small team. We don't have a formal, like graphic designer on staff. We don't have all that. So even all of us, even on the technical side in some way, get involved on the, in this community management or promotional element or membership support or all of those things.
So it becomes part of the work too.
Preston So: [00:12:32] Thanks, Tim. Well, I'm gonna go ahead and open the can of worms, but I think everyone's kind of curious about Drupal 9 is here. And I think everyone's kind of curious, you know, is this going to be a challenging, upgrade cycle or what's involved? So I guess my question for you all here today is, you know, you know, we've got a lot of people who are watching this.
They're they're looking at Drupal 9. They're excited about all of the advancements, but they're a little bit wary about the upgrade process. So what can an organization that is looking at moving to Drupal 9 based on the work that you all have done, the incredible progress and the incredible advancements you've made in all of these aspects of Drupal's ecosystem.
What are some of the things that you've built or improved on, that allow for these organizations to move to Drupal 9 more quickly or in a more kind of a rich way.
Tim Lehnen: [00:13:23] Let me also, I'll talk briefly about the Drupal 9 update process in general, and then turn it over to Neil to talk about some of the tools that, he's collaborated on with some folks in the community and that the team has collaborated on, that are, really incredibly helpful as well and have been helpful to module maintainers, but as a general rule, we've been sort of talking around this at the beginning of this call, Drupal 8 and Drupal 9, are fundamentally architecturally similar. They, you know, Drupal 9.0, the release that just came out, has the same features and functionalities Drupal 8.9, which also just came out except that it's moved to the latest version of underlying libraries and remove deprecated code.
So this means that anybody who's running an UpToDate version of Drupal 8. is probably ready to do this update just as easily as any minor version update, that they've done over the course of the 8 life cycle. Like the only thing that they need to double check is that the contributed modules that they're using and any custom code that they're using, is actually ready for 9, as well as removed to those deprecations.
And as on that latest implementation of the 9 architecture. So, what's kind of shocking about this is. On the release day, as people were sort of celebrating the release around the world, we were getting tweets and people posting in the Drupal Slack saying I've just done the upgrade, like literally as the release was happening, basically.
and huge portions of the contributed ecosystem were compatible even before release day, which to my memory has not happened before for a Drupal release. So in that sense, it's super incredible, but at the same time, there's going to be people out there listening who still have, a bunch of legacy custom code or who still have a variety of other modules.
And they're not sure whether or not the compatible yet. So there are some awesome tools that are going to support that. So I'll let, I'll let Neil talk about, a few of those different things that people can use.
Neil Drumm: [00:15:15] Yeah. And, really we didn't build any of these ourselves. We helped out with some of them, but these are all very much community driven, there's stuff like the upgrade status module, Drupal Check and Drupal Rector. those are worked on by Gabor Hotjsy and, Ted Bowman and, some of the people at Palantir and really what they were able to do is, leverage some of the more modern coding in a way that's Drupal has been moving to a modern PHP and,
Drupal Rector will, for example, transform, deprecated code into the more current equivalent.
So it will give you patches for, removing a lot of deprecations. I think they have pretty good coverage now. And the bit we, the little part we helped out with was, they wanted to run these, on all, all contrib projects hosted on drupal.org. So, we were able to, work with Ted Bowman to get a script together, to do the, and, throw that onto Drupal CI, used a large AWS instance and, get patches for every.
Contrib module in about five hours, and he's, going through and having those be posted to issue queues for contrib projects. So maintainers will see those and hopefully apply them. And I think they have been applying those patches. And the same tools can be used, for your custom code. So there's a good chance custom code will, be easily patchable to, be compatible with Drupal 9.
Preston So: [00:16:57] Well, I can definitely say that I've seen so many people in the Drupal community and contributors and module maintainers, so excited about, the ability to just run, a bot and have every single kind of, change they need to make you very clearly laid out in front of them.
So, it's a really wonderful tool. And now I want to go into a different part of the stack here, you know, I think we've talked about Drupal and, you know, the actual kind of Drupal CMS. But I think there's a lot of people who are also really, really concerned and worried, maybe not, you know, maybe not as much as they should be, about the infrastructural kind of considerations. How does hosting Drupal 9 change? How does kind of the underlying foundation of Drupal 9 change for those who are hosting their own, kind of, Drupal 9 installations. What does that look like in this new version?
Tim Lehnen: [00:17:42] Maybe Narayan wants to speak to this in a little bit more detail and then talk about some of the things we're doing in our own environment. But you know, there's the, the place to start is the system requirements have been updated, pretty notably because, you know, PHP has been releasing new versions. There's new versions of PHP 7 and some of these older versions that even some common hosting providers kept current, are out of date and in some cases unsupported by the PHP project itself anymore.
So, you know, in an interesting way, open source projects like Drupal and, and others in the PHP ecosystem act by releasing software that increases these requirements helps to move the hosting industry forward and get their infrastructure further up to date. But, Narayan, do you want to say a little bit more about that side of things?
Narayan Newton: [00:18:29] Sure.
In a pretty real way and not surprisingly hosting Drupal 9 and Drupal 8 are similar and they have similar issues because usually you're coming into an environment like ours that has legacy code Drupal 7, sometimes Drupal 6 sites. That are not going away. Increasingly you're not running one monolithic site, but you're running sub sites and we've certainly run a lot of sub-sites Drupal.org Is very much not a brochureware site.
Like we have a lot of pretty complicated, like C code and integrations. So those things don't go away, which means you end up basically having to run different full platforms under these different Drupal versions. How we do that is sort of up to how you want to run the infrastructure. I've done that with, they're called, it's called a slotted installation of PHP where you have multiple versions of PHP or PHP FPM running concurrently.
That can be fine. And in fact, we do that. Already to some extent, to have different pools for the different sub-sites pools, the PHP executors so that they can be tuned differently. And so that each one can run as a different security context. So we can kind of isolate the sites. but going to Drupal 8 Drupal 9 kind of makes that more difficult.
What we've done other places not on the Drupal.org infrastructure yet is actually use containers for this and treat the Drupal 8, Drupal 9, upgrade as a opportunity to switch to a more containerized workflow because it can be. More maintainable than slotted PHP installations. It's likely that on the drupal.org infrastructure, we're going to do similar there, but it's a very large workflow change.
So it's just going to take some work to move to that. Although it helps that a lot of the people On the team do have experience with that in other projects. Other than PHP version. We aren't really going to have a lot of platform changes underneath that. But PHP version is more than enough. It requires some significant changes to how we roll things out currently.
Preston So: [00:21:01] Wonderful. and you know, I think that there's, you know, obviously there's those kinds of considerations that are really important. and the thing I'm really curious about as well is, you know, we've talked about Drupal CMS, we've talked about some of the infrastructure and, but I'm kinda curious, you know, what is the new major version of Drupal mean for drupal.org itself?
And how does drupal.org kind of evolve in light of Drupal 9. Is drupal.org already on Drupal 9. how's how's things looking there?
Tim Lehnen: [00:21:28] Gosh, I wish I could be saying yes right now. I'm so tempted to just say sure, but no, we're not on Drupal 9 yet. and actually the majority of drupal.org is Drupal 7 and people who use groups.drupal.org will know that we have one Drupal 6 site still left on longterm support.
That puts us in an interesting situation. It means that. We like, I think many of the listeners to this podcast are sort of legacy Drupal 7 users Drupal 7 was, you know, the, the banner version of the kind of zeitgeist moment in Drupal's version history up to this point and had, just the, the vast majority of Drupal sites.
And there's a lot of people who even through the 8 life cycle have been still wondering how to make that, that leap and make that jump. And so there's some things that we're planning on doing that I think will be interesting to a lot of other folks. I'd love to get into that in just a second really quickly, in the, in the more minor or in the more Urgent and specific case what a new major version means is often more traffic and more load to drupal.org. We actually had just have to get ready for the fact that we're going to get a lot more attention. So Narayan spent some time with us working on just some performance and scaling stuff. Some, effectively like load protection, denial of service protection kinds of work just in a couple of days before the release to make sure we were ready in case there was a big pickup in interest, and maybe you could hit the highlights of some of those little things.
And then we can talk about some of our plans for drupal.org's upgrade.
Narayan Newton: [00:23:03] Yeah, we have in the past 10 or so years learned that if you create a landing page for a release, you should probably make sure it performs relatively well. I forget which release we didn't do that for, but it was very notable.
There's always going to be one page that people choose to link to when they post the story that there's new releases. Drupal -- or Reddit or Y Combinator or what have you Twitter, and so it's important to make sure that that page performs well. And if possible is entirely cached, there have been releases to Drupal that we actually force cache that page at the CDN.
So, I'm not sure how many people noticed, but some releases not this release, you would be logged in and then go to the download or welcome page for that release. And suddenly it would appear like you were logged out because that page was being anonymously driven from our, from our CDN, not actually from the VMs, running the site, this release, we did not have to do that, but we did look extensively at the performance of that page and a few other pages, Neil, Did a lot of good work on the performance of just the generic page types that we're going to be hit.
And then we made sure that we understood the performance of our anonymous pages delivered through our CDN network. To make sure that the vast majority of traffic that gets driven from release, which is just anonymous people, clicking on a link that all of that would be cached well and cached at the edge.
We also do some CDN level caching for our repository viewer in GitLab to make sure that links that are going to be. Re downloaded a lot and possibly scripted are buffered at the edge. we've also learned that that's important for release day, especially in the age of composer. And also we always, we have the tools that we've talked about before, Datadog for logging and, PerimeterX to keep an eye on bad actors, during release day, which is something that is somewhat.
New for the past few releases, but has become a, bigger concern. we have people that will be testing out various, layer seven denial of service attacks leading up to release to try to cause trouble for release because it's fun. We have people that will find the email address of the infrastructure team and add them to numerous mailing lists, just to flood inboxes, to prevent work.
we had some this time, some, mailman subscription, spam that we're working around. So the security aspect of this is also there. The security slash harassment side is, there as well. I need to be prepared for. This one went fairly well though.
Preston So: [00:26:00] And Narayan, I think you just mentioned, you know, some, some really interesting, kind of tools that really are important for, protecting against obviously some of these really, really tough attacks from nefarious actors.
And I, you know, I think there's a lot of really interesting learnings that obviously the Drupal Association has gained. You know, some of these tools that you just mentioned, you know, PerimeterX, for example, are these things that other organizations that are running on Drupal can use as well?
Narayan Newton: [00:26:25] Sure. PerimeterX is a interesting example because it's a very large application, but if you're really having issues with bad actors and distinguishing between them and legitimate use, drupal.org, is an interesting case because there's a lot of legitimate use of drupal.org that for a normal site would definitely not be legitimate, but it's totally fine for people to be scripting things around drupal.org. We want to allow that. So the detection of that versus an actual bad actor, that's trying to repeatedly exercise, a known bad path on the site to try to cause load problems is difficult. And PerimeterX is one of the tools that we use that has been really excellent at that.
And they have a support team that will work with you to, configure their tool better for you, which is useful because it is a very complicated tool with a lot of rules that we don't necessarily want to become an expert at. Also it integrates with, Fastly, our CDN. So the actual Varnish, VCL, and Fastly for our site, you can see where it calls into the PerimeterX platform and what it's doing specifically, which is very nice for both us to knowing what's happening.
And also, you know, we're an open source project and we kind of want to know what is happening with our traffic. So, yeah, they've been very nice to work with. They would be a great tool. If you are a site that is at risk for this sort of thing. There are obviously lesser tools than that as you would build up to that, but PerimeterX, it's something to think about, certainly.
Preston So: [00:28:11] Absolutely. And a lot of these considerations that you just mentioned, you know, I think, they're, they're obviously a top of mind for a lot of, performance and scalability folks. And actually here on the Tag1 TeamTalk show, we just covered a new open source project from Tag1 called Goose.
It's a load testing tool written in Rust. And, please check out that episode for anyone who's interested in, load testing and scalability. so let's go back to kind of, your topic, Tim, that you just mentioned here. Yeah. You know what, so what's exactly the kind of what's what's steps ahead.
Are there for drupal.org in terms of getting to Drupal 9? I understand that, it's not quite on Drupal 9 yet. I don't want you to, you know, give me a, a date today, but, what's involved in making that happen.
MarkerTim Lehnen: [00:28:52] Yeah. So, it's a really good question. We've been talking about different architectural solutions to accomplish this, for a little bit, for a little while now.
And I think, you know, don't hold me to this cause we may, we may evolve the plan a little bit further, but I think we've landed on a plan that's really quite promising. So it involves, a number of things that Narayan alluded to earlier in terms of the, either slicing or containerizing different parts of the infrastructure so that we can simultaneously have, you know, some of our sub sites on Drupal 9 and some of our sites, on, on, still on Drupal 7 while we're sort of in process on the migration, I think to step back like.
The most important goal for us is that we don't have this like two year blackout where there's no new features and there's no support that advances the community because we're just busy trying to do a big platform migration, right? Like that's not a situation anybody would ever want to be in and we don't really need to be in that.
It's not, it's not a place where we have to find ourselves. It shouldn't, it shouldn't be that kind of lift, but we need to be clever about how we do it. And I think our ultimate approach, is for some of the smaller sub-sites. So api.drupal.org, or jobs or localized perhaps, we'll probably do a more traditional, you know, replatform from the current D7 site into a Drupal 9 site, and that'll be relatively straightforward the way that you might imagine any kind of regular changeover, for certain other sites, there's the still a remnant of the legacy association sub-site, most of that, what we've actually done is moved it into drupal.org itself as a section of the main.
www.Drupal.org and like the only thing still running there is when we run elections, and we're going to migrate that off too. So rather than finding ourselves, replatforming all of these sites, we're going to try and sunset some of them and, you know, remove some technical debt, clean things up as much as we can and where we need to maybe migrate some functionality into where it's more useful, where we're taking a similar approach with groups.
Then finally there's, You know, drupal.org itself, the main site www.drupal.org, which has, you know, it's the largest site by far. And it has a variety of user activity, marketing activity and resources. It does a lot of things, and so for that site, we're considering an approach where, we would basically run the seven site and a nine site simultaneously and use the CDN layer to redirect you to the appropriate.
Site based on the path. So for example, if we built the, sort of front end of drupal.org and kind of the marketing content on Drupal, mine as an early part in the process, we could use the CDN to direct people to any of those paths, to the Drupal 9 site. But then as soon as they click over to say the issue queues, if those aren't ready yet, that could bring them back to the seven site.
That's still in the progress of being updated. And that way we can actually progressingly update this large. Monolithic complex site, based on different paths and areas of the site, that have kind of discrete components. So that's conceptually what we're thinking about doing, and there's considerations there we'd have to manage identity.
We don't want you to suddenly. Be logging in, in two different places at once. If we can help it. we have to, you know, think about different places where data might be fed from a view of a seven site into a sec, into a section that we're now trying to move to a nine site and make sure we can do all of that.
But in principle, I think that's going to be a way that we can deliver migration for drupal.org is a large site, and yet still have capacity on our very small team to be delivering features and support for the project as a whole. We don't want to stop that just to undertake this migration. So that's that's I think what we're going to do.
Try and do, and I think, I think it's an approach that could be very useful to some of the listeners out there who may have find themselves in a similar position. If they have a large, you know, a large installation and there's these discreet components that they need to, that they'd like to tackle one at a time.
Without having to just wait to the end, to, you know, switch over all at once. there's one case study on drupal.org. If you search for the, I believe it's the MuleSoft case study, they used a similar approach. They did the CDN, path based, redirection for different sections of the site, when they did their 8 migration, and, I think that might have some useful information for anybody with listening who thinks, ah, maybe we should try that.
Narayan Newton: [00:33:25] See Drupal can be a microservice.
Preston So: [00:33:29] Well, you know, we'll see, we'll see if one day at Drupal becomes a service mesh potentially, consisting of multiple services. We'll see, anyways, maybe a very, very long discussion. Not outside, not in the scope of this particular episode.
Tim Lehnen: [00:33:41] When we have the Drupal 11 Tag TeamTalk, then maybe
Narayan Newton: [00:33:44] we'd have someone.
Preston So: [00:33:46] Absolutely. Well, one thing I know I'll be doing this weekend by the way, is I will definitely be, you know, over the course of the next few months, I'll be looking at some of my favorite pages on drupal.org and looking at that Metatag generator, to see which version it's on. Cause I'm really curious about the strategy and I really want to see which parts of it.
I want to see if I can predict your roadmap a little bit by seeing, Hey, okay. So they're working on localized first. Now they're working on groups. Okay. You know, now I know, so I can kind of sneak in with a few tweaks. We'll see. So one thing I did want to want to want to know, by the way, Tim, you said something about 10 minutes ago that I think, you know, we glossed over a little bit and that is, you know, you mentioned, you know, I'll quote you directly.
You said drupal.org is not brochureware. It's a very complex and a very involved custom Drupal site. One of the things I wanted to ask about is, you know, this is a very challenging implementation to manage. what is it like to be cleaning up all this technical debt? you know, what's it like from the inside, for people who are out in the wild, who are, who are also thinking about some of these maintenance challenges and, and, management challenges.
Tim Lehnen: [00:34:51] You know, it's interesting. I'll actually, I think I'll let Neil speak to some of this because he's been, on the, engineering side of drupal.org in terms of this custom code and where a lot of this came from going way, way back, to through many major versions of Drupal. And I think he has a unique perspective on this.
Similarly, Narayan's been supporting it for an infrastructure side for quite a long time.
Narayan Newton: [00:35:14] and you know, I created most of the second, technical debt. So,
Tim Lehnen: [00:35:19] You know, to be fair, but it's some of it we create for ourselves. What I will say in general is. I, as someone who manages the technical team, I have never seen an engineer more happy than when they can, you know, when then when there are more deletions than insertions in their next Git commit.
Right. so, at times that opportunity to, to remove technical debt, is actually motivating, in some ways, cause you feel like you're, it's taken a weight from your shoulders. But you know, the trick is getting that time to prioritize it because when it's not feature delivery, as I'm sure everyone knows every engineer who's listening to this, it's like, yeah, but you know, I, I've got to do some features delivery.
And you know, this is why we take the kind of approach that I'm talking about, where it's like, can we combine this removal of technical debt with. Some sort of related upgrade. We, we did that with the landing pages this time around actually, just as a super minor example, Drupal 8's landing pages, when we launched Drupal 8, used the OG theme module.
So they actually were themed totally separately from the rest of drupal.org. And there's some overhead to doing that. And by the time we got to Drupal 9, we'd had, we'd added new editorial tools to drupal.org for our own internal landing page building. And we just didn't need any of that. So, Neil, we've got to remove quite a lot of quote code.
How much was it? You know,
Neil Drumm: [00:36:39] it was a theme based on the Omega base theme. So those like 40,000 lines of codes from Omega.
Tim Lehnen: [00:36:48] That's a good day. That's a nice commit. I mean, Neil, do you want to talk a little bit more about. About Preston's question about just like what it feels like managing this much legacy.
Neil Drumm: [00:36:58] Yeah. I mean, it's, I always try to clean as I go and, you know, try to leave less technical debt, when employing a feature then than before. so yeah, the landing pages was a big one. We still have the, the one kind of, I guess Drupal 6 era, a landing page we have is the Drupal 7 launch page, which is a custom, template, which has held up pretty well, but it's not something that will be, going in the same form into a Drupal 9.
And yeah, doing some, work with the community on the, getting involved guide that's old, book pages, which most of the other book pages have been migrated into other content types. There are more, more modern, you know, into e-references to keep track of the hierarchies and, who's maintaining what, so.
Providing ways for those to be migrated away while one less content type to migrate. And, there was another one of those old landing pages that say let's get rid of, and yeah, with new features, trying to find ways, of doing stuff with, You know, related to GitLab, for instance, doing that in a more headless way if we don't need, the data in our database.
So, hopefully the, javascript rewrite, right, is, won't need too much work if any work, once it's shifted into the new platform.
Preston So: [00:38:31] I think that's one of the things that a lot of people forget about the kind of, you know, the, the amounts of legacy that Drupal has amassed, you know, and it's, and it's, and it's legacy in both senses of the word, not just, you know, old old cruft, but also an incredible historical kind of, you know, journey that, that Drupal has gone down.
And I think it's really interesting now that we're moving into these ideas of how do we address, not just the technical debt in PHP, but also in JavaScript and some of the client side code that is now being introduced. It's very interesting. Um,Narayan, I want to get you in on this too. since you also said that you're responsible for some of this technical debt, what's it been like for you from the inside?
You know, how, how does it feel to be undertaking this kind of renewal and. you know, I think this, this, this simultaneous approach of saying we're going to add new features and, you know, in the process replace some of our technical debt is a really interesting approach. What's it been like for you on the inside?
Narayan Newton: [00:39:23] Well, I think from a systems perspective, at some point you always end up hating what you've built. So being able to shut off things that have definitely outlived their, not usefulness, but outlived there quality is a satisfying, like when we went to GitLab, being able to turn off the old Git servers, where we had a custom written twisted conk, SSH Daemon that was spawning off, Git processes that wouldn't close correctly.
Cause they were hanging file descriptors. And I had a Reaper script that would go and clean them every 15 minutes. That was very satisfying. And so, and I'm currently working on replacing our NFS cluster that, I may have built in college. So it's, it's very satisfying from the infrastructure side. We're close to not done, but at a point where we could pivot into not just legacy, but also. New ways of running things, getting containerization into it, supporting Drupal 8, Drupal 9, being able to change workflow a bit. it's getting more exciting, but there has certainly been a lot of legacy to work through.
Preston So: [00:40:45] Well, I think that, I think we can all agree that we have the best folks, available, and Narayan, Tim and Neil, I think, you know, you three, you know, certainly we are part of this dream team of folks that are really responsible for stewarding, for acting as community stewards. Not only for, things that are visible, but also all of the invisible aspects of Drupal that we all rely on on a daily basis. So, thank you all for that insight. And I hope that our audience also gained a lot of insight into how the day to day of someone at the Drupal association, works and how it goes. And, with that, I want to go into something completely different.
We have a little segment at our Tag1 TeamTalk show called the Aside Tag. It's about a minute per participant on the call. What we do is we share something that's going on in our real lives. An example could be, you know, I learned about a skill or I just cooked a new recipe and I want to start today with a Tim. Tim, what's going on in your world.
Tim Lehnen: [00:41:38] Yeah. So obviously we've been sheltering in place throughout. Well, it pretty much anybody listening to this is probably in the same situation. And some of the regulations are a little bit more relaxed. So lately I've been trying to figure out. Socially distant, day trips. So, I'm in Portland, Oregon.
So I took a drive up to the, McClellan Overlook in Southern Washington, which has good views of Mount St. Helens. and it's kind of a remote kind of back road up that way. So that was very cool. And I found an, an app that's mostly for motorcycle riders actually, called Cali Moto, that's just really cool.
It helps build scenic trips. It's actually sort of deliberately avoid straight line highways and takes you on the scenic back roads. So that's been fun and a nice way to feel like I'm not just stuck at home all the time.
Preston So: [00:42:25] Wonderful. Well, I'm excited to hear more about that. And I'm very jealous, you know, I, I, gosh, I haven't been outdoors, you know, outside the city in a long time.
So, looking forward to seeing those photos, how about
Narayan Newton: [00:42:35] He said outdoors, and I got concerned.
Yeah. I've been looking for things to do around my house proper. And so have been getting into macro photography, which is a photography of very small things. Or actually it's technically, it's a lens that has one to one reproduction so that you can fill the frame with something very small and have a lot of detail.
And it's been very interesting cause it's totally different. Like all the, the rules are all the same, but it's just very, very finicky and yeah, the very stabilized and well lit. And so it's been fun and you can do it in the front yard because when you're doing that, the front yard is gigantic.
Preston So: [00:43:20] That's amazing.
I'm looking forward to seeing those photos too. Neil, you know, we're in the same city. I haven't seen you in months. What's going on in your world.
Neil Drumm: [00:43:29] Yeah, been pretty well, confined here, with the small apartments here. But we have a roof, that's, pretty safe up here or so can get outside a little, get sunlight, replaced my bike commute with pushups, then, actually getting more into, Yeah, I got involved with Drupal.org Infrastructure through volunteering, working on API.drupal.org. That used to be I, that was what I did on the, for a few hours on a weekend.
But I really hadn't been doing that, stuff outside of work, for a while. But. Now it's all kind of blending together, but, yeah. Getting some, workouts and fun stuff, on the side, that's not necessarily driven by our roadmap.
Preston So: [00:44:15] Well, Neil, I will say that even just one pushup of yours is more physical activity than I've done this entire lock down.
So props to you. Meyers, what's going on in your world.
Michael Meyers: [00:44:25] Well, I live outdoors. We live in a rural area right now, missing the city a lot, but, my problem and I've talked to throughout the saga in many of our talks is a good internet connection, which is why I'm sitting at the local fire house right now.
And I recently learned, so I found a Hill on our property that, I get a cell phone signal with on a mast. so I've been doing a lot of research on how I get from this antenna. Down to the house, which is, you know, over a third of a mile away. And, you know, there's all sorts of different options and I'm not sure what the most cost effective is, but I didn't know that, power over Ethernet extenders existed, for both like your, you know, your traditional CAT, you know, five and six cables as well as like a power over co-ax.
So that, that was really fascinating to me that you can run, ether, net over things like co-ax with power for, you know, four or 5,000 feet. so super cool.
Narayan Newton: [00:45:22] And you can Amp it there.
Michael Meyers: [00:45:24] What's that.
Narayan Newton: [00:45:25] And then you can amp it there.
Michael Meyers: [00:45:27] Oh, I didn't know that.
Yeah, connectors. my concern is like voltage drop over distance.
Now I need to. I need some help. Maybe I'll tap you Narayan to make sure that at the end of that line, I'm going to have enough to make it work.
But,
Narayan Newton: [00:45:41] I mean, I electrocuted myself a lot in the data center, so I wouldn't trust me that much.
Michael Meyers: [00:45:48] Plan B is like a solar setup with batteries, but, you know, anyway,
Preston So: [00:45:53] You know Narayan, I wonder if those shocks, led to some of these great ideas that you have all the time.
All right. Well, now it's my turn on the Aside Tag. And, you know, obviously here in the United States, we are, undergoing a period of deep pain and suffering this week. And I do want to take my, to dedicate my section of the Aside Tag to, the pain that everyone who is watching and supporting Black Lives Matter and who are seeing what is going on in the United States, to pay attention.
We did have a moment of silence for, George Floyd and all of the other victims of police brutality over the last few years on our last episode. But today, instead of sharing an update of my personal life, I would just like to, acknowledge, the losses of the incalculable losses of George Floyd, Brionna Taylor, Ahmaud Arbery.
And I want to encourage also everyone who is watching this, if you are located in the United States or if you have local organizations to support, there are lots of organizations that are partnering with Black Lives Matter and partnering with anti-racist groups to, prevent these events and these horrible circumstances from ever happening again.
Working hard to fight for the right kind of policing and the right kind of politics that we need in this country. I want to call it a few organizations here, Color of Change, Black Visions Collective, Blacklivesmatter.org, the NAACP Legal Defense Fundl, We Claim The Block. These are all great organizations that I have encouraged our audience to donate to and support in this time of need.
And I also want to highlight one of Tag1's own cherished customers, our own cherished client, the ACLU, the American Civil Liberties Union is one of our Tag1 customers. We deeply cherish them and their work, and I highly encourage all of you please to donate and support all of these initiatives and organizations. With that, this is all the time we have today. So I want to say thank you so much to our guests and our panelists today. All the links that we have been passing along throughout this episode are online with this talk. And if you did enjoy this episode, Please remember to upvote, subscribe, share it with your friends and family and share it with your grandma who was still quarantined.
I hope and check out past talks at tag1.com/tagteamtalks . And as always, we'd love to hear your feedback on any topic suggestions about this show Tag1 TeamTalks or about our sibling show Core Confidential, The insider guide to Drupal core. The way to do that is to send us a little note tagteamtalks@tag1consulting.com
I want to really give a big thank you to Narayan, Tim, Neil and also Michael today for joining us on this episode. And we'll see you next time.