Transcript: Day in the life of a Core Maintainer & notes on Drupal 9 readiness - Core Confidential #1

This is a transcript. For the full video, see Day in the life of a Core Maintainer & notes on Drupal 9 readiness - Core Confidential #1.

Preston So: [00:00:00] Hello and welcome to Core Confidential, our new series, the insider guide to core development in Drupal.

[00:00:06] I'm Preston So, editor in chief at Tag1, and it's my pleasure today to be talking about Drupal Core today with our very own Drupal core committer, Fabian Franz, VP of software engineering at Tag1. And today we're also joined by our dear friend Michael Meyers. managing director of Tag1. So this is a new series that we're doing.

[00:00:24] It's a very, very new segment that we've started to launch here at Tag1. A Core Confidential is meant to be an insider's look into exactly how Drupal core produces all the wonders that it does in our day to day lives. So without further ado, let's go ahead and jump right into our list of topics for today.

[00:00:43] I think that everyone's really curious right now about some of the things going on with Drupal 9. I'm hearing about a lot more people updating their websites to Drupal 9. I'm hearing about a lot more module updates as well, to Drupal 9, but what's going on in Core exactly. I understand that there's kind of a focus on deprecation [00:01:00] and module management to meet this release deadline.

[00:01:02]Fabian, what exactly is going on with Drupal 9 these days.

Fabian Franz: [00:01:06] So just quick, caveat. I'm the Drupal 7 maintainer, I've nothing to do with 9 No, but my colleague, Catch , Nat Catchpole is Drupal 9 maintainer, he's helping preparing that thing, and I get to know all the nice things.

[00:01:22]So the thing about Drupal 9 is that's the most important part is it's basically a release in the next stage. That means it's a borrowing stage. It totally means, now with Drupal 9, there's things that are effort, upgrade path. Everyone hates a upgrade path. That's why we skipped it completely, right.

[00:01:43] And also those things that deprecated code. We've deprecated so much code within Drupal 8 for you pc reasons obviously, that this code needs to be removed now. So it's really a lot of busy work, but once that's done, Drupal 9 can ship, basically. So those are kind of some blockers.

[00:02:04] So, despite what you normally have, like, like there's a new release coming out, et cetera like that. And, there will be lots of new things. No, that's not Drupal 9. There was kind of the approach that we as community took with Drupal 8, that we've been using this LTS approach, this approach of having always little minor releases.

[00:02:27] And then, Steady releases all the time so we could introduce new features all of the time. So all of the exciting stuff basically has already happened in Drupal 9. So in Drupal 8 and so Drupal 9 really just removes the old code and, basically all the duplications and ensures there is nice upgrade path from Drupal 8 to Drupal 9 and then it's ready.

[00:02:50] So Drupal 9, and that is very, very important, will be so, so, so much closer to Drupal 8, than any major version release of Drupal before basically. So, where before you had a lot of vary, like from Drupal six to seven or seven or eight, like, like what all, or even five to six, what all you have to port, what all you have to change, what all you have to do.

[00:03:14] In essence, if you've been following along Drupal 8 to Drupal 9 and always. Took care of in your contributed modules and your custom module to remove your deprecated code. That was deprecated in Drupal 8 already. You are already kind of like ready for Drupal 9. So, this is pretty cool in, in this whole approach.

Preston So: [00:03:35] That's wonderful. And I think, you know, I do hear a lot of people working on Drupal 9 readiness. There's obviously a lot of really amazing things like the Rector. module. but I'm kind of curious, you know, you mentioned that there's a lot of things that people need to do to get ready for Drupal 9.

[00:03:51] And I know that there's, for example, a beta testing program, what can people who are in the community who are really interested in getting their code ready for Drupal 9 doto, get in touch with this beta testing program, participate in it? Are there any virtual events coming up for core development that relate to what, say contribution sprints or things like that?

Fabian Franz: [00:04:11] Yes, indeed. we were posting the direct dates in the comments here, because I don't know, but I've just heard that at the time, the DrupalCon, North America would have happened. There will be a huge Contribution Day that basically replaces a normal sprint we would be doing, and this Contribution Day should make Drupal 9 ready, should do a lot of things basically.

[00:04:36] So the core of Drupal 9 is basically taking core off, but we also have some contrib. We have all those modules that have been ported from 7 to 8, which have been used for 8 or have newly developed for 8 and all of those need to be made ready for Drupal 9. And fortunately, again, it's much more simple than before because basically you just have to look at [00:05:00] the list of deprecations from Drupal 8 to Drupal 9.

[00:05:04] Everything that was deprecated in Drupal 8, and then you have to basically change the module, and that's . The other possibility obviously is just to install Drupal 9, install your 8 module and see what breaks, see what works, and fix what doesn't work anymore. In that, chances are high that might just be working, so if you've never used any deprecated code, because you've started just in the last year with Drupal 8 or whatever, then chances are high it will just work on Drupal 9 and it should be, that's how it should be.

[00:05:39] Yeah, and we will be posting the, definitely, we'll be posting the link to the minor release beta testing program. That can also help for people that want to support like Drupal 8 releases being more stable or in the future, Drupal 9 minor releases.

[00:05:54] So that whenever something goes into beta, you can install it already on your production system. No one would notice admin to the staging system. So, that you can then, use all of those and then see what breaks basically. So really, the main contributions we are looking for right now is the testing , and then there's also, this module upgrade program that's so important.

[00:06:19] So that when Drupal 9 ships in the ideal case. Everything that's available for Drupal 8 should be available for Drupal 9 at that point. That would be like, perfect. That would be amazing. And it's, it's, it's really, really important too, because once Drupal 8 is released, you're expected to upgrade to Drupal 9. This is not like before where basically, they had been like support forever in that, but, really, really, you should upgrade from Drupal 8 to Drupal 9 earlier than later, because there's no Drupal 8 extended support like we have now.

Michael Meyers: [00:07:01] So what's the probability? I mean, some people are not going to update to Drupal 9. you know, like I said, maybe you install it, maybe it works.

[00:07:09]Maybe you don't have the resources to make it work. So what do people who are on Drupal 8 that can't upgrade or, or aren't getting, going to get around to upgrading for a long time? What do they do if it's no longer supported?

[00:07:24]Fabian Franz: [00:07:24] I mean, basically, It should be simple to upgrade. But I do think, so far Drupal 7, I know that once Drupal 9's released, Drupal 7 is end of life. So, there will be several companies, including Tag1 that will be providing a Drupal 7 LTS support. That means long term support. That's paid support program that we already have.

[00:07:47] Very successfully for Drupal 6. So for Drupal 6, you're already covered. For example, if you use the Tag1 Quo, we'll be expecting to you do the same for 7 and most [00:08:00] probably, as you just said, also for 8. I mean, why not?

[00:08:04] The thing is, it's the same work, basically. You have a security fix coming out for Drupal 9, LTS vendors for 8, 7, and 6 will be notified, like usual after security issue.

[00:08:18] They can prepare releases and do that and people will pay a fee of some extent, to be commercially supported in that. So that's basically a good situation. So if someone really doesn't want to do that, they could still participate probably in some LTS program. Yeah.

Michael Meyers: [00:08:38] What is all this code that's getting deprecated?

[00:08:41] Like you give us an example, you know, w what is it and why is it being pulled out? Like, what's the difference between 8 and 9?

Fabian Franz: [00:08:48] So basically, deprecations, something. so historical Drupal has grown and grown and grown and grown so basically from each version, from four to five, five to six, et cetera, et cetera.

[00:09:04] We've put layer on layer, on layer, on layer, but that means we could never basically remove any coat. so, when Drupal 8 was shipping, we even have still had some procedural code from Drupal 7 in Drupal 8. For example, 2% message and those things, we don't necessarily want to continue shipping into Drupal, but.

[00:09:29] Nine because we want to have most class-based code. which everyone has switched to by now, but those procedural functions still exist, so within Drupal 8, it was impossible after it was released to remove them, due to the backwards compatibility policy. So basically the promise was whatever happens within Drupal 8, Will not change in a way. However, what we can do is we can deprecate it. And so, for example, these [00:10:00] procedural functions of how, what, where, we still had a lot of, those had been deprecated. And now all of this code is basically being, being removed. Lots of procedural code. Then we have some little older APIs that are no longer being used, et cetera.

[00:10:19] So basically you can search for deprecated in their Drupal 8 code base, and then you'll find functions and then you create, can create a patch and you can remove those.

[00:10:29] Oh, that's one possibility to contribute in removing deprecated code. Maybe search for if there's an issue or that function already because then you can contribute to that, but if there's not, you can create a new patch.

[00:10:43] Preston So: [00:10:43] That's amazing. And I think it's, it's really great that we've got, some really nice incentive structures in place. Actually, I know that Gabor Hojtsy, for example, on the Core team has been, basically, incentivizing a lot of folks to contribute these updated modules. with monetary contributions, it's going to be amazing once these, [00:11:00] Drupal 9 modules are fully updated and we've got a really nice litany of modules available.

[00:11:05] So I wanted to take a little bit of a different direction here cause we are well into this episode. you know, you know, I think you mentioned something very interesting at the start of the episode, Fabian, which was that. You work on Drupal 7, and others are sort of responsible for Drupal 9 and other, sort of versions of Drupal.

[00:11:20] I'm curious, you know, what is the life of a Drupal core committer like, and given that there's only a few core committers per version of Drupal, what does it actually mean to be part of the team?

Fabian Franz: [00:11:32] It's quick, but it's also, it's an immense responsibility. that's first and foremost how I would describe the job.

[00:11:40] It's a responsibility, when I joined the team. It was the 1 millionth site in Drupal 7, so this dreaded 7.5.0 release, that most everyone, even 3 years, et cetera. I've got some messages about modules. In the modules, tables still be there in that thing. It affected me inside, so it didn't break anything, but it was like - a little bit unexpected too. After years of no messages on the Drupal 7 site, suddenly getting messages about a bad module being loaded and that person important thing because it actually slowed the site down a lot. So it was a large dodger back to fix in that. but it was also a lot of flack we've done. Other things were, which affected lots of sites where like security updates, security updates, for example, for the fuzzy issue with the, where you have like a file, the files on disk and, those far files , were used in several contributed modules that were pretty popular, like GYP and other things. And they suddenly stopped working. And, even though we made little things or flight listing and other things, they had to do some work around. So this is how little things that need to be fixed, like security issue needs to be fixed, can affect. Lots and lots and lots of sites. So basically, whatever I do, it still ends up probably on half a million websites right now. because those are the ones that update the news version.

[00:13:12] Some are just not updating. They should be updating because Drupal 7 there's really not much risk in that. And Drupal 7 we are right now in basically the last maintenance date. I fortunately just recently got, got a new, core co-committer and McDruid (Drew Webber) . and he is, he's basically preparing things right now for me.

[00:13:34] And, I'm doing basically, I mean, basically the last gatekeeper, like, like whatever wants to go into Core, it needs to go to me. You shall not pass. so, but several of the things passed, for example, just this morning. So the really good example, I've, approved, eight, 7.4 compatible PHP 7.4 compatible patches for Drupal 7, and McDruid (Drew Webber) will be getting them in later today.

[00:14:02] So, that's really good. And, yeah, for me, the role was never, when I originally joined the team, David was release manager and I was framework manager. That means basically an architect, responsible for framework decisions and things. And then David and Stefan, basically left. And, I was all alone.

[00:14:24] And then I got another core committer, but basically suddenly I was all the things that three of us, framework manager, release manager, and and even, product manager for the thing. And. That was never what I wanted to be as a core committer. Because what my strength is, it's really reviewing code and ensuring no bugs are introduced as much as I can.

[00:14:43] I mean, everyone makes mistakes and ensuring really high quality code is answering core and it's keeping stable for all those seven sites still out there. And it's still a lot. And that they're just liking 7, that they're keeping at 7 and wanting to be on the [00:15:00] stable platform. And they will probably also join one of the LTS programs in the future and just be on seven forever.

[00:15:07] Make listen 50 years. It will still be uncertain, maybe, you know? But yeah. and, seven really is a great platform to build upon. So, but as you can see is still modernized, for example, for PHP 7.4.

[00:15:22] We have full PHP 7.3 support, PHP 7.4 support, hopefully soon. And I think we also got to mySQL 8 patch in by now, so that's pretty cool.

[00:15:34] So that's basically, yeah, one of the things. Yeah.

[00:15:38] Preston So: [00:15:38] So, out of curiosity, you know, you know, we've spoken about, some of the work to, some of, you know, some of the distinctions between what it's like to be working on Drupal 7 versus Drupal 8 . but I'm curious, you know, in terms of working on.

[00:15:52] Releasing an actual new version, you know, let's say, and, and this might relate a little bit less. Well actually, you know, it does relate to Drupal 7 cause we're talking about, you know, sort of [00:16:00] minor version updates and, and some of these sort of minor versions coming out. Can you give us an example of, of kind of what a typical day is like when you're working on a new version of Drupal, let's say a minor release, a Drupal 7 or, you know, something like Drupal 9.

[00:16:15] What's it like to be actively developing a new version of Drupal.

Fabian Franz: [00:16:19] So, it's definitely, a totally great feeling. Often it was, basically, shortly before release you would go through the queue will look at what things are RTPC, what things are high priority, but things are low priority. And then say basically, Hey, this is a nice patch.

[00:16:36] We really want to get this in for the release still. So then you're, you're downloading the patch. You test it locally. You ensure it's all working correctly. You check the code, you go away, drink coffee or tea or whatever you like. For me, it's more tea, sometimes coffee, and then go back and review the code again and then do something else.

[00:17:00] Work a little bit ,work a little bit, work a little bit, and then you go back and review the code code for a third time. Just to make sure, really you thought about all things, sometimes I even sleep at night over it. If there's still time before release. but hopefully I have. And then I review it again and then when I'm totally sure, then it goes in basically.

[00:17:20] So, this is also one of the reasons why core processes take some time and it sometimes feels like it's so slow moving, etc. This is for safety reasons. Basically.

[00:17:32] It's for, because I personally double check and double check on that. and now in Drupal 8, especially with the process they are having this pending like the beta version and then the frequent releases, et cetera.

[00:17:46] And they're a little bit more liberal in getting things in, they're still doing a very, very great job. But it's, it's still, usually they are more quicker to commit and more quicker to revert in those things, but that's really just as Drupal 7 as a conservative version right now. And, so that's that point.

[00:18:09]and because, there's less. There's more tests, obviously in Drupal 8, there's less breaking changes in Drupal 8. Usually Gus obsess deprecation and, and, there's also a little bit less edge cases. So for example, in Drupal 7 we changed one completely unrelated . Which no one thought about would do anything.

[00:18:32] Then we got reports that it broke some strange contributed module somewhere down the road. So it can happen,we revert the change that it's made, a new release or hopefully it was, maybe it was even found before release because someone beat tested it, so that was good. but yeah, Things can happen. And just the little bits, people are much more bleeding edge in Drupal 8.

[00:18:55] And I had. Installing the beta versions on the stage and testing servers they are testing things before they get released, And you know that every six months, a new release. So things are not piling up as much. and that's how Drupal 8, I will say, diverts a little bit.

Preston So: [00:19:13] And out of curiosity, you know, if I were, you know, I think that there's a very big difference. between obviously some of the incremental changes that people make around bug fixes or, you know, things that are, that are, that are documentation typos, for example, you know, code, comment typos. but I'm curious, you know, you know, I think as the arbiters of core development, you all have a very high standard for, let's say, new features being added or changing how something's architected or how it works.

So refactoring some of the underlying pieces. How does the process for introducing a new feature or making a larger scale change differ from something like a simple bug fix or a smaller issue?

Fabian Franz: [00:19:54] the short answer is don't. takes pains a little bit. we hadeven still during the Drupal 8 cycle, this huge patches for the 472 kilobytes, a huge branch to be managed.

Et cetera, and those things look okay after a while, even through a 400 kilobytes patch community, down to that, once you've gone through it, you go through it several times, you get it finally committed. But the problem is the work t doesn't stop there, one such patch can lead to like 100 issues of technical debt that are like follow up on that. And this was kind of like these large breaking changes of Drupal 8, which several persons said that we should be doing this pain ones and then we have it through over. We are no longer doing that. with Drupal 8, Drupal 9. We are no longer doing these things. It's very important that we are doing that things.

If you want to introduce a feature, break it up into what things you need for it and then basically check. And if, if some, if you need to do like some breaking changes with some API, consider introducing a new API instead basically.

Look at what you need for it and then iteratively improve on it, like start small and then iteratively one step, one step, one step, one step, one step, one step.

And suddenly you have your whole feature in core like, but you really need to break it up. And check it out and do what is needed to get the simple things in. Obviously you can create a so-called meta issue where basically you're, or a plan issue where you, you plan out what needs to happen to get this feature into core.

But then it's, it's important that every part of that thing is independently useful. And nice to have for that thing. And then, basically the contract here is Core is Always Shippable so if after developing this feature to 50%, you get your dream job and you have no more time for Core because you really want to. work or even better scenario, you have a full time job and you suddenly meet the girl, a boy, a few drinks or whatever, and then like you don't have any more time for Core, completely vanish, et cetera. So this feature is now 50% finished and. Maybe there's right now, no one who can finish it.

It's important that core is still shippable at this point. So all of that contribution of those 50% of your feature is already giving Core a huge win in that. So that's why we much prefer an iterative approach. And that's also the whole experimental module saying that basically. Because that is a contrib module.

Contrib works well, you introduce it into [00:23:00] Core as an experimental module. Your feature. And, once it's a stable, et cetera, then at one point there's not too many new bugs, not too many things affecting sites, et cetera. Then it gets to be a stable thing. And the nice thing about an experimental module is basically you can still make breaking changes because no one should be relying on that already.

[00:23:23] They should only be relying on that until the stable. So there's a very good compromise between contrib and core. This experimental stage within core. So that's, that's one part. As for a bug fix, obviously, you have read to test, you prove it, it breaks, and you fix the bug.

Preston So: [00:23:41] I think we're all very grateful for the ways in which experimental modules have really reinvented how we can leverage new features in Drupal very quickly without a lot of kind of overhead and sacrifice, but also being able to do that without the worry that it'll, you know, potentially, be something that you have to strip out later [00:24:00] or it's a very, very good kind of intermediate stage.

I love it. So we are at a time today on this first inaugural episode.

Oh, go ahead. Yep.

Fabian Franz: [00:24:08] Sorry for, and just, just for the, eh, I really didn't answer your, your day to day thing. I just realized, so, the important thing that the core committer does day to day is he cleans the RTBC queue. It goes with the RTBC queue, checks every issue, and then basically, says just came though in or this doesn't go in.

So that's the day to day.

Preston So: [00:24:33] Wonderful. Well, I know that we're all very, very appreciative of all the efforts of the core committed team and all of the work that you all do day in, day out. we are at a time in this very first episode of Core Confidential.

I did want to make a couple of notes here that we didn't get to today.

The first is, as a reminder, there is no extended support for Drupal 8 which means that if you are going to. Stay on Drupal, you need the upgrade from Drupal 8 to Drupal 9. It's not going to be the same situation as it was for Drupal 6 or 7. So please make sure [00:25:00] to upgrade to Drupal 9 as soon as that release lands.

And also did you know, by the way, that Drupal 10 has already started? The branch has been open for a while. I believe there's also a plan issue already available. that's been, currently, talked over quite a bit within the community. And of course there's also more specifics in the issue queue.

We'll have links to both of those within the post. Surrounding this video. Thank you so much for joining us on this first episode of Core Confidential The insider guide to core development. I'm really grateful to our two friends today, Fabian Franz, VP of software engineering at Tag1, as well as Michael Meyers, managing director at Tag1.

Thank you both so much for your time. Thank you all in the audience and see you next time on Core Confidential.