Talking Drupal #370 - A Smaller Core

• What is meant by a smaller core
• What modules have been removed already
• What is the process
• Chopping block terminology
• Which modules are under discussion
• When they go to contrib is there a maintainer first
• What is the impact to users of the module
• How long will they be maintained in contrib
• Why is this important
• What modules are next
• What is the commitment to being a core system maintainer
• Is there going to a sub release process

Transcript are generated with AI and lightly edited, therefore will not be 100% accurate.

Nic  
This is Talking Drupal weekly chat about web design development from a group of people with one thing in common. We love Drupal. This is episode 370 A Smaller Core.  Welcome to Talking Drupal. Today we're talking about a small core with Theodore Biadala. Theodore has been contributing to Drupal for 13 years 10 of which he has been the JavaScript core maintainer. And for a bit more than a year, he's been a provisional core JavaScript package maintainer alongside Sally Yan. He's currently working at Acquia and the Drupal acceleration team, and supporting efforts to get Drupal 10 Released on schedule. Welcome to the show. And thank you for joining us.

Theodore  
Thanks for having me.

Nic  
I'm Nick Laflin, founder and enlightnened development and today my co hosts are. As usual, John Picozzi Solutions Architect at EPAM. Welcome to the show.

John  
Hey, everyone. And I actually just realized the show's called a smaller core, but has nothing to do with working out so don't worry, we're going to talk about Drupal.

Nic  
Also joining us for the third week as guest host is Taryn Almendariz is developer advocate at Pantheon and lead of the Drupal Diversity and Inclusion Initiative. Welcome to the show.

Tearyne  
Thanks for having me back.

Nic  
You have a new module the week John, this, I think came from you.

John  
Yeah. So I don't know if anybody's ever used Swagger UI as a way of showing API documentation. But recently, I had a request to, to use this in a project that we were building. And I actually added, there's a mod, there's a module for that, right. So the open API, UI swagger module actually allows for you to be able to use the swagger library with open API UI to be able to show your API documentation within Drupal. The reason the reason I bring this up is because it was super easy to set up and install, and provides really great documentation using the swagger library for your for your API. So there are a couple of module requirements plus the swagger library as well as a requirement. So there's there's some things to install in addition to this module, because it uses the open API UI modules or set of modules as as kind of under underlayment. But really quick and easy way to get good, pretty good API documentation up and running for your Drupal site. So I recommend checking it out if you if you have that requirement, or if you're using an API with your Drupal site. And you need to provide some documentation to people.

Nic  
And does it integrate with things like JSON API and like, automatically document that or

John  
Yeah, like so we're, we're using JSON API. And literally, I installed the open API UI module and one I think, dependent module and then this module, and then installed the swagger library and like, boom, my whole die. All my documentation was right there. I was like, Oh, this is pretty spiffy. I was very spiffy.

Nic  
Very cool. Okay, let's move on to our primary topic this week. Let's let's start with an easy question. Can you tell us when we say smaller core, aside from John's joke, in the intro, can you tell us what we mean by smaller core.

Unknown Speaker  
So it's all about making Drupal maintenance, maintainable long term. So right now everybody's like pretty big. So it needs a lot of work to be able to maintain it, release it and just keep it up to date with dependencies. So the idea is to make Drupal easier to maintain. So we can focus more on the important parts of Drupal core. Drupal is Drupal core and the contrib system. So that's, I mean, the, the coverage for the features is going to stay the same with core and contrib. It's just a features within core. We want to make them more focused on what Drupal core is supposed to be addressing, addressing as problems and that way we can make sure that we solve those problems really well. And if the rest to contrib, so it's going to be providing a very solid basis to build on.

John  
So I, that makes a ton of sense to me. And I've like, I mean, I don't know if I would say a big supporter of this, but like, I think it makes a lot of sense and like making core smaller and more like more portable and compact is is something I definitely agree agree with, right? So part of this right is obviously taking certain modules and moving them to the contrib space. And we're going to talk plenty, plenty about that. But I'm wondering if you can tell us, like, what modules have already been kind of removed, or from core like, kind of, not really, through this process, but like, in the past has been like, kind of how you've seen like, oh, well, we're going to put this in contrib? Because it doesn't really make sense to be in core.

Theodore  
Right. So I wasn't really involved in in the previous effort. So I've only looked at what's been happening for the last past year or so. So during the last actually, I don't think we have many modules removed, like in Drupal 6 or 7, or that kind of things. But what what's been removed from nine to 10. So we have the aggregator module, the CKEditor 4 module, where the CKEditor module, which ships with CKEditor, 4 library, the Color module, how Quick Edits, RDF. RDF was, like, pretty, pretty nasty to get rid of but you know, it happened. And as far as themes goes, we have Bartic, Classy, Stable and Seven out of go now,

John  
in the past, or is this on the table? This is this is going to be like a clear and blatant expression of my my lack of knowledge right here, but like the Forum module still in core, or is that maybe on on the docket to be talked about as to whether it should or shouldn't be?

Unknown Speaker  
Well, it's still in Core. But it's pretty much going to be moved out of core at some points. So I don't I don't have the proper timetable. But, you know, we started with the easy module, I guess. Well, RDF and agrigator, were not easy, but they were really hard to maintain. So, you know, we made the effort to get them out ofcore to make the life of core committers. Easier. That, you know, color, and the pretty easy thing to get rid of.

John  
I can't even tell you how happy I am. That color is out of core, because I'm like, I'm pretty sure every Drupal site I've ever built, I've shut that shut that module off on so.

Theodore  
Yeah, because, you know, it's a nice feature, but it's not really a core thing to have. But yeah, so we started with some easy modules to kind of make sure that the process works properly that you know, finding, I mean, we're probably going to talk a bit more about the process, but making sure that everything runs smoothly before we can, you know, say okay, we we want those five modules to get, you know, out of go and into contrib. So we are trading the process and starting to work pretty well. And now we're going to move on and go down the list,

Nic  
I guess. Well, speaking of process, actually, before we move on, I think it's important to also highlight that it's not just a matter of moving something to contrib. And that's the end of the day like there are other things to consider. So for example, you mentioned CK editor, for it was one of the ones being moved out. And CK which means CK editors moving in. And I remember seeing an issue in the Drupal infrastructure channel in Slack, maybe two weeks ago, where that process with the composer dependencies is ending up with people are ending up with two CK editors in their project, one in the contrib folder, and one in the core folder, because we have something with the same dependency name, but it's moved, where it lives. And so so there's some, you know, these types of things. You know, if it's your own project and your own thing, sometimes it's easy to move things around. But when you have a lot of complex dependency chain sometimes Just moving something isn't as simple as like, Okay, well, we're gonna move over here and say that it's done, you know, composer might have other ideas about that. And then, you know, in Drupal doesn't like having libraries in more than one location because you know, it, it wreaks havoc. But but those are the types of problems that the core team is, is looking to solve with this process. It sounds like,

Unknown Speaker  
yeah, that's. So I've been out for three weeks. So I'm not sure exactly what the structure is on that. But I think that started on the solution for for this, which so this is part of the process that we need to iron out before we, you know, move more modules out of core to make sure that this works properly. So we don't trip up people, basically.

Tearyne  
Alright, so I know that we're talking about this process in general, but what is the that process for selecting what gets removed from core? What stays in? Like, how does that work out? Is there like a council of like core removers?

Unknown Speaker  
It's not council of core removed. So the decision ends up on the project owners, so we have four of them today. You know, that's Drees, Webb chick, Gabor, and Roy, that, you know, our product and decide kind of what should Drupal core be, I guess. But it gets input from the whole core committer team as well as contributors. Because if you know, contributors really want like, I guess, even if they really want the project or not, don't I mean, project didn't have the last say in this. So yeah, the other one that decide and if we don't agree, we escalate to Dries. So and he's the one that decided in the end at

John  
Drupal con, I think, sorry, more specifically, Drupal con Portland. Right. Dies seems to say that there was some sort of like voting criteria where people were kind of voting on, you know, or weighting the modules that that could potentially come out of core? Can you talk about that process? A little bit?

Unknown Speaker  
Yes, yeah. So there's been, so it was just within the core commiter team, right? It's not open to the whole world. Because essentially, it requires input from the core committers for the job on the module. So there has been three, four or five that 12 people scan have contributed to the spreadsheet where we say, okay, is this is this module, giving one of the fundamental fundamental foundational capability that was talked about, like before, thing, the content modeling, and three others. Content modeling, and content delivery, content authoring and systems operation. So those are the four things Drupal should be doing. And then deciding what goes into each of those topic is, you know, still up for debate, but at least it's kind of a guideline. So we say, is this module? Do we feel that this module belongs to one of the four topic? Yes, no, then we have, is this module easy to maintain? Or is it a pain to maintain? Like the, like, for example, if you take the van module, is it really, you know, something that should be in core, but at the same time, it's really easy to maintain? So, you know, it doesn't really cost much to keep it in core. And then we have the kind of usage of the module. So is this module used on a lot of sites that we know of. Or if they're not, so this data, but the usage is kind of biased. Because it's only for site that enabled the update module. Because we look at the data that comes from drupal.org. And I think it was like, if you have a module that is enabled on the standard profile, it gets different rules as to what is considered like a high usage compared to a module that is not enabled in the Standard Profile.

Nic  
I mean, that makes sense. So,

Theodore  
so yeah, those three things get kind of put on into one single score, I guess. And I think Dries talked about the thresholds for In the ads, if you have like, if you're higher than two, you're safe. I mean, the video is safe. And it's, you know, it kind of belongs into core. And if it's under it could be considered, like nomination essential, I guess, or not worse to keep in core with obligates and all the process around maintaining a module. Okay. And it could be them feed from being in country.

Nic  
So I'm curious about some specifics. And because, you know, certain modules being core or in contrib, has been a discussion that's been, you know, long term listeners will know that this is something that I have some opinions on. And I'm curious, I guess, on two levels, I'm curious what your opinion is on some of these specific modules. But before I get into the specific modules, what modules are in discussion for being removed? I mean, obviously, color and aggregator are deprecated. Right now, which means they're pretty much on the way out, I think poll was removed from 7 to 8, if I recall correctly, all right. But are there other modules that you think are like, Hey, these are CKEditor are but are there others that are on the chopping block that you're like, hey, probably in the next version, or So these ones are going out.

Unknown Speaker  
So I wouldn't say chopping block. So this is kind of an issue I had with kind of terminology we use around talking about all this. Because I mean, some module, putting them out of core, kind of say, they're not going to thrive in contrib, because the use case is not really relevant anymore. Because nobody uses it anymore. So we get it out of core to reduce the burden that we know it's not going to get great life afterward. Because, you know, it's not really a use case anymore. But there are some others that could be improved from being out of care So I like to say, like the module graduates from coer. So it's kind of

Nic  
interesting, too, because now that you mentioned it, yeah, like sometimes it can be hard to get a patch in core or get a fixing core and get a feature sometimes, and it's a rebirth

John  
the module is reborn in contrib

Nic  
yeah, so So sometimes moving it to contrib means that I can get more more attention as well, or, you know, additional maintainers.

Theodore  
So if you talk about like, specific modules, like the, so I can't say this one is going to be moved out, because I don't know, it's not my kind of decision to make, but I know of the few like the statics statistics module, or the history modules, history, people have proposed, you know, improvements for like nine years in the case of the history module, and nothing made it in because it's just not a priority for the computers. So those modules could gain from being moved out of God, even the kernel module could be improved, more easily out of core. And all of those modules have a very strong foundation now, because I've been in court for a long time. So like, we have test scritpts, that, you know, make sure that the basic use case are not going to break when you make new release and everything. So we we know, it's kind of safe to move out, because delta could test coverage. So as long as the new maintainer is going to be like minimally, looking at adding test coverage, that should be fine. But yeah, those like we have. I mentioned the ban module as well be kind of looked at, to move out of coal book. I mean, this whole thing, of

Nic  
course, yeah, book was one of the ones we were thinking about, because we had a show on book maybe maybe two months ago. And it's kind of the discussion around that is interesting, because core has some specific, really strict guidelines on things like test coverage, right? Like, you know, even if we're contrib maintainer has test coverage, if they break, if they've been failing tests, there's nothing stopping them from releasing it. Right. But the core, you know, the core team is much more strict about that, you know, they've made those commitments that hey, I'm sure there's some exceptions. In fact, there's, if you're interested in core coverage, test coverage, there's been a lot of discussion in the infrastructure channel about that recently. So that might be a good good insight into that. But yeah, there's, there's a commitment there, which kind of put winch to that burden that you're talking about, like the maintainers have, you know, there's a responsibility there to make sure that they're not breaking things for people using it, that's a little bit different than when it's in contrib. That being said, like I said, I do have some opinions here, I have some questions about the modules that I've always been curious about, from the course core maintainer side, if you if you know, you know, where these kind of fall in that spectrum of they should be moved to contrib. Or, you know, if the maintainer is happy to continue maintaining in core, you know, the first one is forum, I think John mentioned this, you know, if I think I'm going to build a forum, I don't know that I'm using the core forum module.

Theodore  
Yeah, I mean, will you even use Drupal?

Nic  
I mean, no, probably not.

Theodore  
So yeah. There's your answer. Yeah. It's, I mean, to me, it should be getting out. Is it on the list? It's, yeah, it's like at the bottom of the list of stuff that needs to be moved out. So it's, I think it's going away at some points. And this is one of the modules where we are not quite sure that it's not going to be, you know, nobody's going to spend a lot of time improving the form module to make it up to the standard of forums that you have. Although, from other softwares, so, yeah, it's going to graduate but you know, kind of retire your as well

Nic  
Yeah, what about tour, because tours, now the module that I uninstall on every single project that I started, and I understand that it has really strong, it has really, you know, if you need it, there's nothing else like it, right? It has really good use cases. But it's also like, you know, why is it in core?

Theodore  
Yeah, so it's one of the things that you have the four kind of foundational capabilities, but you have also like, strategic value thing. So it's kind of a core committer. You know, superpower that say, okay, even if it's not in the use case, even if it's not used a lot, we still want to keep it because it's important for Drupal, and Drupal's future, either, because it's, the technology might pick up later. And we need to be ready and have it in core already. Because, as in the case of tour, it provides the feature that's really important to have, even if it's not used a lot. Like because when you need it, you really need it.

Nic  
Yeah. Makes sense. We already talked, you know, there's a few statistics based ones like history, statistics, tracker, you know, are those. You talked a little bit about it? Are those set to graduate as well, at some point? Are they just going to be maintained more actively?

Theodore  
So, I mean, to me, they should they should graduate. Because I mean, so with the list and the scoring, Like they are below the to the score 2 that Dries talked about? Yeah. So they are not strategic. Either they have their how to maintain, or they're not, they don't fit the four functional capabilities of Drupal.

Nic  
Okay, I think that makes sense. I uninstall most of them, too. I mean, I find that if you don't plan for them, they become real performance  problems. And I think I've only ever needed them on one site. Just two more, because I don't want to belabor every core module, but I have two more that I noticed today looking through the list, I didn't even know basic auth was a thing. Drupal core.

Theodore  
Oh, yeah. This one is I think it's in the its for your like JSON API and all the API headless. Because you want to have authenticated requests, and you don't want to, to have like, OAUTH or something.

Nic  
Yep. No, I have used it now that you said that. No. Okay, that makes sense. And then the last one, and I'm just gonna ask this one again, a little bit more specifically, because we had a show and so recently, but what are your thoughts on the book module? Is that something? Uh, because again, it's one of the things we're not too many people need it. But if you need it, it's the only thing out there. It's unique.

Theodore  
Yeah, I love the book module, actually. I mean, this whole show is because I reached out to you after the book, module episode, where you said, you know, you're like, oh, yeah, we don't really know what's getting out of Drupal or why things are getting out. And I want to make sure that everyone you know, knows about the process and what has been happening. So personally, I love have the book module. But it's not considered like strategic capability or? Yeah, I guess it's not like it's above the 2 score, but I'm not sure it's going to stay in very long.

Nic  
I mean, the thing is it provides something unique, right? You know, taxonomy, taxonomy exists as a thing, because there's a hierarchy, right? And then nodes exist because their content book exists, because it gives you the ability to have a table of contents in a hierarchy of content, without without a convoluted, you know, taxonomy representation.

Theodore  
Actually, it's below the 2 score. So yeah, it's going to be on the next batch of module we are looking to remove.

Nic  
Okay, it's good to know,

Tearyne  
I just want to say that I appreciate like the paradigm shift from chopping block to like graduation or retirement, it feels so much better. It's like, you're gonna be allowed to grow out little module or sign for you go out to pasture old friends, like, there's a lot better.

Theodore  
Yeah, and because, you know, the, like, the code is, the code is old. So there's a lot of knowledge attached to that code. So talking about getting rid of it, it's kind of talking about forgetting all of this, and I am not really happy about this framing. So, yeah, I prefer as well. Talking about kind of keeping that and just moving it somewhere else. That might be a better place. Yeah.

John  
It's, it's probably a nicer a nicer, we use of terms when talking about somebody's hard work, right?

Nic  
Yeah. It truly, yeah. And it truly is what you're saying, like, some things, just, you know, because of the commitments to core, some things really are hard to implement, and contribute really is just a better space for them. You know, contrib can innovate in certain ways. I mean, Drupal core innovates, in a lot of ways. But contrib can innovate in different ways. Sometimes, it can certainly iterate a lot faster.

Theodore  
And actually, I wanted to sorry, I wanted to go back to that the fact that core the innovation, because Dries talked about a lot of you know how to innovate faster. And in this last keynote, he said, you know, we're not going to lower the bar for the quality. So we need to have different ways of improving the velocity or the innovation speed. And this is one of the ways well, it's if we make the cost model, it's easier to maintain the document our team, you know, by definition ism maintenance team, it's not like an innovation team. It's not the people that are driving the initiatives, for example, like some of them are initiative leads and that kind of things, but we're looking at people outside of the core committer  team, to kind of manage the innovation, and the core committer team is there to make sure that everything works and you stable, kind of.

John  
So let's, let's dig into that a little bit, a little bit, because I'm curious when, when a module core module is identified, and it's, you know, decided that it's going to go into the contrib space, I'm wondering, to do you guys first identify a maintainer for that, to say, like, Hey, do you want to, like take this on as like a responsibility? Because like, you know, let's, let's just, I don't know, let's take book, for example, right? Like books going out into the contrib space, that module, right needs? needs? A maintainer needs somebody to kind of like, you know, facilitate it a little bit. Are you guys identifying people to fill that those roles? Or are you just kind of like doing it yourself?

Theodore  
So I guess there's a couple of situation. So, the ideal scenario is going to be someone wants to work on the module and improve it. So that person is going to be, you know, pretty much a maintainer for that module inside the country space. But yeah, the nothing moves out of core without maintainer. So there's not going to be like an orphan module that we move out or call and just live there to,

John  
you know, even for something even for something like forum where it's like, we might not see much like innovation and development here.

Theodore  
But you might need to date for new PHP versions? Sure. So, you know, as long as your security issues, so as long as the module is not kind of outright deprecated it needs someone to maintain it to make sure that, you know, the minimum quality that we have in Drupal around security and that kind of things is ensured.

John  
Yeah, that makes that makes sense. You know, and I, there's a little piece of me that hopes that some real passionate forum user is out there and like, wants to, like, you know, make the Drupal forum module like the best, best thing it can be I build a whole contrib ecosystem for it,

Nic  
I have every feeling that's gonna be Michelle, right? I mean, if you don't know, Michelle, I think maintains the advanced form module. And I just remember her being she was one of the first people to interact with me on IRC. She wasn't she wasn't the first. But she was one of the first people to interact with me back in the IRC days and helped me out the one website that I use form on, which is the website that also made me realize Drupal probably isn't the place to host a forum, because of the amount of spam that made its way into that site in a short period of time, but you know, I remember Michelle being very, very involved in any and every single form issue on drupal.org.

Theodore  
Oh, yeah, you know, finding the maintenance in the country space is one of the first tasks because we're not going to move something out if there's nobody to maintain it. So sometimes a core committee is going to say, okay, that's, you know, it's easier for me to maintain it in contrib than to maintain it inside of core. So there'll be okay, yeah, I maintain that. It makes it easier to move out. But yeah.

John  
And I mean, maintainers can always change too, right? Just because somebody takes it, when it comes out of core doesn't mean they have to maintain it forever. Like that's not that's by nature, not what we do so.

Tearyne  
So for modules that were removed in the past, like we're talking about learning from our history, that's why we're graduating them or retiring them to keep that around when they've been removed in the past. How's that impacted the people that are using that module?

Theodore  
So I'm not actually sure, because there's not many instances of we have us doing that. And I don't think there'll be any removal with compositor things around. So I guess Drupal 10 will be the one that removes module when people lose composure, so before we talked about the color module that got removed, but I don't think it was like a huge user base, for that module within the CKEditor one's going to be interesting, because a lot of people have it enabled. Yeah,

John  
yeah. So last last week, last week, I talked a little bit about upgrading CKEditor. And, for me, it seemed seemed pretty intuitive and pretty straightforward to kind of walk through the process. Because it, you know, there was a deprecation warning in Drupal, that was like, hey, this modules going to be  5deprecated. Like, you got to do something. And then upgrading to CKEditor 5. was was, you know, installing the module from the contrib space. And then just kind of following following the prompts to get it get it working. I imagine like, that's going to be there may be a little bit of like the reverse of that when a you know, something goes into contrib. Right? You're gonna probably have that warning, but is the goal to totally piggybacking off this question is the goal there to have the contrib module ready before the actual deprecation happens. So like, so you could essentially make the switch before it's actually removed from core are those things going to be pretty like it's removed from core and then the contrib spaces is up and running.

Theodore  
So you don't need a release to have the deprecation. But you do need to have like a stable release in contrib. For us to remove it from core. So for example, having a stable CKEditor module inside of contrib is a blocker forwards in Drupal 10 because people can't, you know, if you don't want to update to CKEditor five and you want to keep this editor for you can still use the entry module like, easily, but it needs to be like a stable and maintained release for you. Right.

John  
So, so let's talk about like something like color, right? So like color colors being removed. Is there currently like a color contrib module living out there?

Theodore  
So I see it's already stable. Yeah, that's a really easy like September.

John  
Hey, look, there it is. Color backport.

Theodore  
Because there's no like, walk on it. And it was already walking inside, of course. So you just take the code from coal and put it in country, even real estate. And that's

John  
right. So that was gonna be my other question is like talking about like, people using it. Right. And like their, you know, their pain point, right? If if the code that's in core is the same as the code that's in the the contrib module, like there's pretty there's like almost zero Frank friction there. Right. In theory.

Theodore  
That's the That's the plan. Yeah. Well, wonder two released in contrib, should be the same as what you didn't call?

Nic  
Well, I'm curious too, about things like issues. Like, you know, we were talking a little bit before the show about some long running issues in core, you know, core, you know, sometimes there's an issue has been gone for three or four years. And part of the idea of moving something into contribute is to start taking care of those are issues for particular subsystem and core moved to the new contribute space so that they can be addressed or

Theodore  
Yeah, yeah, we have we have heard from the TA on that. And they just must move the issues.

Nic  
Okay. And does that does that affect issue credits? So do those issue cards no longer become, core  credits if you were working on that, or

Theodore  
think they move? Yeah. I mean, the new ones, I think the old one stay like that. Because the issue, the issue that are fixed are still in core. Right? We move the open issues to the

Nic  
finish, which makes sense. I guess. That's interesting. That's an you know, an interesting, like, this talks about this, this kind of explains why this shows the thing though, right? Again, it's not as simple as just moving the code over to a different place. Like, there's there's processes, there's, there's probably merge requests and issue forks and things that will have to be rolled, right. And it's gonna be a lot more complex to reroll, because it's a completely different codebase. Right? It's a subset of another code base. So

Theodore  
that's a really good question. I have no idea abour merge requests.

Nic  
Yeah. And what about like back? Like, if, like you said, the 1.0 is equal to what was in core. But what what point in time was that? You know, if there's a security release, now, colors still gonna get updated in core? You know, are they just going to fix that independently on the contrib space Or are they just gonna, you know, what does it diverge as soon as it's been split? To 1.0?

Theodore  
Yeah, for security topics, you have the security team in the loop. And they look at core and contrib, because the same thing for them. It's the same responsibility. So they're going to want the module maintainer that there was a security issue on their module, invite them into the security team issue, because they have a specific tracker for security issues. And this will get solved that way. So if you have a security issue in the color module, it's going to get fixed on 9.5, if it's no, it needs to be fixed in 9.5, and it's going to be fixed on the contract module at the same time, and really should be synchronized because, you know,

Nic  
yeah, yeah, that makes sense. And by the way, I have to say the security team is very good. I mean, they respond so quickly to like, I've opened a couple of security issues in the past, and they respond, usually within hours. And I know that Stephen has reported issues and they've been fixed within, you know, 12 hours, like the security release was fixed within four hours for the next release. So, you know, they're, they're very good. They're very responsive. You know, they take the job very seriously. Very talented. It's, it's pretty impressive. It's definitely one of the selling points for Drupal as a whole, right?

Theodore  
I think Yeah. And it's, yeah,

Nic  
I can imagine the the volume that they deal with.

Theodore  
Not everyone is friendly as well. So yeah,

Nic  
I can I can imagine I see the public queue. So, so I guess the question is, kind of going back to a recurring, I guess, a semi recurring question that we've had for you You've mentioned, you know, a lot of these things are moving to core so that they can. They're graduating from core to contribs that can be iterated on more. But there are some other modules where it truly is just a straight deprication. You know, CK editor is a good example, you know, CK editor really is kind of strictly is kind of strictly being deprecated by CKEditor 5, right. Now, there are going to be people using the older version, and it's going to be named, it's going to be maintained for certain periods of time, what what is that period of time? Is it just, it's going to be maintained until the version of Drupal that it was on is end of life? Is it as long as the maintainer feels like it? Or is that normally defined?

Theodore  
So it kind of depends. So if we take the CKEditor example, this one is pretty specific, because CKEDitor 4 as the end of life. So it's the end of next year, I think. And the issue was that we can't put that into Drupal, 10, because our support window is longer than 2023. And we can't commit to maintaining ckeditor 5, the library, right? So it needs to get out of core, so that it can be the module can be deprecated, when you ckeditor four, sorry, is end of life. And that doesn't impact the core support window as well. So this one should be obsolete. When ckeditor 4 is the end of life. Or maybe like the citizens or team wants to sell supports, they can probably do that as well, because it's your the folks that make the city that are five stuff as well. But for also module, it's kind of up to the maintainer, right? If he, and maybe it's not even up to the maintainer, right, it's even up to the community. Because if the maintainer doesn't want to maintain the module, someone else can just claim it at some point, as a whole process on the top to retrieve like, access to a module that is abandon.

John  
So like, yeah, when I when I wrote this question, admittedly, it was more it was less about something like CKEditor, which is like very clear in kind of like, its need for deprecation, right? And more in the vein of like, you know, color , forum, right? Where are those modules are kinda like, and I keep going back to the farm module, and I'm not picking on it. I'm not picking on it. I'm just using it as example. Don't send me nasty grams, because you love forums. I have a fond place in my heart for forums too. But yeah, I guess like, in that case, right. Like, you know, I guess it just kind of lives on for as long as it lives on as long as somebody's willing to maintain it and kind of like, keep it keep it going, right. It's not, there's never like a, well, we'll see, like, it'll last it'll be there for a year. And then maybe we'll just like, you know, we'll just discontinue it or deprecated. Or, you know, get rid of it. So,

Nic  
yeah, I think that I think that makes sense. I mean, what else can you do it right. But it also highlights something that you said to me just kind of like the Drupal 8 to Drupal 9 upgrade, the reason why Drupal 9 came out, was because Symphony was no longer going to be maintained it Symphony 3, I think it was, you know, it was end of life, and Drupal as a community. One of the reasons why we moved to symphony is so that we didn't have to maintain that infrastructure, that we could pull our resources with the symphony Foundation, and all the other, you know, projects that use it, like Laravel, and SilverStripe, and etc. You know, that was the whole point of it. But it sounds like moving things from core to contrib can help with that problem on that, I guess, is our problem help with that? On a smaller scale as well, right. You know, the Drupal community doesn't want to take on maintaining CKEditor, like you said, beyond its end of life, which they couldn't do. I mean, if there are huge, you know, if there was, you know, unlimited resources, that's something that you could do, right, you can say, Okay, well, I'll just take on maintaining that for the extra two years that we need to, rather than removing it, but it sounds like moving it to contrib strikes that balance of allowing the people that need to, you know, need that they can expend those resources there, but it's not burning out the core maintainers trying to maintain something that's, you know, a large portion of the internet community at large has moved on from because it's end of life. You know, because that's, that's part of the process too. Like you said, there's, there's not a huge number of core maintainers there's not a huge number of core committers right. You know, your resource Horses are finite as well. So we want to make sure that you're using them in the best way. Possible and having the most impact.

Theodore  
Yeah, yeah, that's, that's yeah, that's a balance to find. And it's trial and error, right. So we're going to try something with getting modules out of core. And maybe it's going to work, maybe it's not going to work. But that it is something different than what we used to do. So

Nic  
I'll just be happy that there's less modules to uninstall when I set up a new set.

Theodore  
Well, if you have like the whole recipe, initiative, yeah, I'm excited about that. Yeah, you're going to do that too, like that. So you don't have to.

John  
There may be more modules to install.

Theodore  
Yep. Yeah. But there was poses as

John  
new and exciting modules. So I think we talked about this at the at the top of the show a little bit. But I kind of want to come back to why this process is important for Drupal core, right. We talked about, obviously, the show title, smaller core, you know, everybody can kind of get behind fundamentally, why like a smaller Core is a possibly happier or better Core. Right? But I'm just wondering if you can highlight, like some of the key points into, you know, why going through this process is helpful. I think one of them that you mentioned, which is interesting is is innovation, right? Being able to innovate and improve some of the really, really the core not to overuse the word core, but really like fundamental parts of Drupal, right, that may not necessarily get as much love as they should, or as much innovation as they should. Are there any other really like important reasons why this, this process exists?

Theodore  
So yeah, so there's, there's a few considerations, right? So you have kind of trying to define what Drupal core is supposed to be. So that's a very old bike shed. Like what should Drupal be? What is Drupal? It's like, fundamental question that the product owner should kind of try to solve or respond to in some cases, I think the best we have is Dries's vision. So the report is for ambitious site builders. So we want to kind of focus Drupal in a direction. And some of the stuff that we have to then call doesn't fit that direction, right. So it's time and energy spent on things that are not while they are important, but not to the vision that we have today. So they might have been important in the past. And that's why it's in call that today, they're not as relevant. So we just want to keep working on the stuff that is relevant for the direction that we have today. And want to focus the thoughts on those things. And that's why if you graduate, graduate or retire your stuff from call other people for which those modules are important. They can spend the time to make them great, or, you know, much better than what they are today. So there's that there's reducing the dependencies, because we depend on a lot of external libraries. So you mentioned symphony, like a grid aggregator, relied on some very old libraries as well that we had problems with. So we want to get rid of that. That reduce the work for the security team as well. Because if there's less party stuff, there's less monitoring to do. It's also kind of makes things faster to install. If you don't have as many modules with like, kind of focus, vision, security. That's kind of the main topics for why Drupal with a smaller core is important. And

John  
all of those things make complete sense and make me very excited to have a smaller, smaller core.

Theodore  
And in the thing is that we have a smaller care but we are going to make it much easier to add stuff to to core with Project browser. Right? Right. So it's yes, it's going to be easier to add stuff to your Drupal now.

John  
Yeah, even even recipes or starter kits, like all of those things are geared towards, like you actually getting the modules into your your version of Drupal that you need to do what you're trying to do. Right.

Nic  
I also think that a smaller cord self is kind of a misnomer, just because if you compared, you know, the number of modules and don't do it a point oh, to now. I mean, I'm okay with the, with the experimental module, you know, process, new features are getting put in every six months or so, or a couple of times a year, right. Yeah, I think inline form errors wasn't, you know, pretty core, when drupal 8 was released, you know, migrate wasn't part of core media wasn't part of core. So so it's not even like, what core actually isn't getting smaller cores still getting bigger. And doing some big things. I think it's about you know, allowing these modules to get the attention that they deserve. Right. And control for some for some modules, that attention is core, like views clearly should be a core.

John  
Right. It's also not saddling somebody with a module they don't necessarily need, right, like, you don't need forum functionality. Like there's no reason your code base should kind of be like carrying that around with

Theodore  
it. Right, just in case. Yeah. Yeah. Open Days.

John  
So like, and, you know, to be fair, your point was very good. Nick, I thought you were going to make a comparison to another, well, well known and very widely used CMS that I will not name. But yeah, I mean, I think I think you're right, like, it's, you know, it is definitely a misnomer. But I think also, like, there are instances where like, Hey, we're removing color, we're removing, you know, aggregator we're removing potentially forum, you know, like, those things have like, code cruft that come with them that now don't have to kind of be shipped with core. So I mean, that's kind of where, in at least in my, in my simple brain, I go, Oh, it's getting smaller.

Nic  
Maybe smaller than the day before, but smaller year over year, not smaller year over a year.

John  
Well, sure.

Theodore  
It's not a small core, like you're more focused core Right.

Nic  
Yeah, exactly. And I think that this along with the experimental process, and you know, the six month point release has been some of the best improvement improvements, project management wise for Drupal in years. I mean, it allows, it's part of the innovation cycle that we were talking about earlier, right, the ability to add new stuff over time. Before it could only be added at a major point release, which is sometimes many years in between, but with with the experimental process. Now, six months can be six months.

John  
It's like battleaxe, core versus scalpel core. You know, we're, we're working towards scalpel core where like, you're gonna get a very focused, focused product, right.

Tearyne  
All right. All right. So we keep asking you questions where I'll tell you about the future right now. Right? I'm going to ask you to draw on your 13 years of Drupal experience. Make a prediction here. What modules do you think will be removed next, after Drupal? 10?

Theodore  
Well, I mean, that's that's not too hard. So it's going to be what I think it's going to be like focus, forum statistics,history. The one we talked about those are not like very hard to book as well.

Nic  
What about tracker?

Theodore  
Oh, yeah, it's it's on the list as well to remove

Nic  
is that list public? Or is that public? Is it

John  
isn't tracker you? Isn't that the module that's used to like track usage statistics for Drupal. Like for modules in your all three of

Nic  
those modules, I think do earn similar spaces, like history tracker and statistics, I think.

John  
But statistics is like no node usage. Isn't I don't even know what history does. Sorry. I've used Drupal forever and like, but like I thought tracker was what kind of phoned home and told told Drupal like people were using modules but

Theodore  
like the upgrade, update.

John  
Okay, see ya.

Theodore  
Use. tracker in Drupal 10. So probably not even true. Drupal 11? Yeah. So, yeah, I think the more kind of that's going to be my own opinion, not the opinion of the core team, right. I think the one that should probably graduate, you know, maybe migrate, you know, migrate started in country pescar.

Nic  
Something about that recently.

Theodore  
It's I mean, it's not to say it's not important, but it's like, you know, we wanted to have migrate, make sure that Drupal 8, Drupal was Drupal 7

Nic  
to Drupal 8 and Drupal 9  was covered, right.

John  
But, hey, that's actually only use migrate

Theodore  
for that. That's really interesting.

John  
Yeah,

Nic  
I do. I use migrate for all sorts fo things things.

Theodore  
But core itself doesn't choose migrate to the update, right? To provide.

Nic  
Yeah, so So yeah. So to clarify that for our listener. So I think migrate can move into courses or support a migration pathway natively from Drupal 7 to Drupal 8, or Drupal 9. So once Drupal seven, I think the plan was once Drupal 7 was end of life and fully removed, migrate after that could be removed, because Drupal itself if you're going from 8 to 9, or 9 to 10, doesn't use the Migrate module. You know, for example, 8 to 9,

John  
you don't need to migrate, you don't need to migrate, you can upgrade at night. And

Nic  
it was just it was just replacing symphony and removing deprecated code, you know, wasn't a it wasn't a major change, you know, right. So things go

John  
migrate definitely could, in my, in my opinion, my humble opinion could definitely go back to the contrib space, right? Because after Drupal 8, there's an upgrade path to 9 to 10 to 11, to xfinity and beyond

Tearyne  
seven to 11, you have like a whole other set of

John  
but there's a whole there's a whole problem there. Right? And you need to you need migrate at that point, like and at that point, you can pull it in, you know, from control

Nic  
IP for Yeah, but you're not using at that point, you're just migrating from a source to a destination. You're not Mike. Like I think the point of it being in court really was you could say this is a Drupal 7 site and migrating from, and it would do a lot of that auto discovery. I

John  
mean, we all we all got that. I think we I think we're all in agreement with that. But like going forward, it's not necessary. And I think I think it really does make sense to move to move to contrib. Because like, you know, thinking of sites that I've built, like, right over the last, like Drupal nine sites that I built, like, there are uses for migrate that aren't just like migrating content, right. So like, in the past, I've used migrate as a as like, a feeds substitute to do like more advanced feeding into from other systems. Right. So like, there's still a use case there. But like, ultimately, I don't know that it it's necessary on a wide a wide range of Drupal 9 sites, right. So yeah, I can definitely see, I can definitely see that one, that one coming out at some point.

Nic  
I've used it also for like re-architecting. Like, if you change a content type structure, new create new one, you can use it to migrate content from one content type to another.

John  
The other thing there though, is it's not something that you would use on necessarily on a production site, right. So like, that's the other aspect there that if it's in core, like it has to ship out to production, like again, increasing your you know, your file footprint, if you will, if you have it in a contrib space, you have the ability to add it as a dev dependency and then you know, bring it in as dev dependency and then remove it from production or staging if you need to. So that's actually super interesting.

Theodore  
Yeah, and you know, maybe the contact module as well.

Nic  
Oh, contact yeah, I've never used that but I know

John  
John Oh, whoa, whoa, let's slow down a second here. Slow down, because I will I will fight I will fight on that one. Because

Nic  
for a never I've never used it

John  
for a while. I would actually use core contact in place of web forms because Web Forms was just so felt like such overkill for like building just a simple web form. Sharon's give me giving me looks right now. I think she might think I'm insane. I don't know. But like, literally, I was like, Ah, you could just like literally turn on the contact module and like, hey, there's a contact form and like, here are a couple of things you can do with it. Cool. Works out of the box. You sometimes I like I install web forms and gosh, I I literally love Jacob brockwitz. He's like the best human being. Not like, I recommend using web forms if you need complex complex forms, but like, in the early stages of like web form, I would turn that thing on and like, it would just overwhelm me. And like, I'd be like, No, I'm just gonna go to core contact, because it's easy. So I think for people who are like looking for that kind of like, off the shelf, like, I'm gonna grab Drupal and build a website with it, like, core Contact Forms is important. Yeah, sorry, I just went on a tangent there

Tearyne  
earlier find my passion. Oh, I was gonna say my look was because I found your passion for the topic, very endearing. And I was like, all he really cares about this.

Nic  
I mean, it highlights the need for this discussion, right? You know, the, the, you know, it's not as simple as, Hey, I've never used contact, John does or like migrate. Like, there's people that use migration, every single project in production, there's people that use tracker on their site, and it's critical to them. But you know, from the maintainer side, there also needs to be there needs to be balanced. So,

John  
hold on a second. Hold on a second. Sorry. I just like like a lightning bolt. This hit me. And this is actually a question that so we earlier in the show, we talked about, like how the like selection process kind of goes for like for sunsetting. These modules, right. I'm wondering, is there any sort of, because obviously, this is like a core maintainer, you know, Dries conversation, right. But is there any public forum to get like public insight on some of these? As far as, like, hey, like, what is the public think of us taking these modules out of core?

Theodore  
I think that happens in the issue queue. So those are, that's going to be an issue that say, remove X, Y from core. And then people are going to say, okay, yes, no, there's going to be some discussion there. But in the end, it's the core maintainer responsibility, because they're the ones that actually do the job of maintaining it. So if they are not willing to maintain it anymore, there's not much you can do. And if you can be a high

Nic  
bar, yeah, a high bar, it's hard to become a core maintainer. And it needs to be maintained. So basically, if you want to stay in core, you have to become that maintainer, and you have to have a track record. Like there's criteria to be a core maintainer. It's not like I imagined that that if something gets proposed to be removed, it's pretty likely that it's going to be removed.

Theodore  
Yeah, there's been discussion before, it's not like, someone just thinking, Oh, maybe we could get rid of that.

Nic  
Yeah, yeah, exactly. And like, like we've been saying, it's not like, hey, remove, it's deleted, it's gone forever. No, it just moved to contrib. So if it really is that important to you can still maintain it. And you'll probably have an easier time contributing to contributed module than to a core module as well.

John  
I'm not going out to install Contact Form module. I'm not doing it, it's gonna stay in T shirts, I'm making T shirts.

Tearyne  
Hashtag save the contact module. I need you to clue me in here, because I'm a little bit outside of what kind of commitment does it take to be a core system maintainer?

Theodore  
I guess co maintainer, you don't have commit rights. So you're, you're basically managing the issue queue. Batch making review. So I mean, that's the there's a whole definition, list of roles in the Drupal community, and the co-maintainer for specific topics that you're kind of in charge of this topic. Like for JavaScript, for example, I'm sorry, good dog. For JavaScript, it's like I make sure that I look at all the JavaScript stuff, try to plan for updates or that kind of things, but I don't have the right to commit anything to go. And when you are a core committer then you have the kind of access to commit things to the Git repository. Okay. And when you're a core committer, historically, you can have scaled down on your patch work. So it's more of a review. Review based role, I guess, making sure that everything you know Pass the value gates, for the quality that we have. But it takes a lot of time and patient patients.

Nic  
So you don't have the you have the ability to make it your responsibility is to maintain the issue queue, I imagine help feed some of that information to the core committers. So you don't have commit rights, but I imagine you get you can more easily get the ear of, you know, a core committer if you if there's a critical patch or something.

Theodore  
Yeah, for the, for the maintainer role for the I mean, for the JavaScript stuff, it's a separate repository. So I do have commits rights to this other repository, but not the Drupal Drupal repository. So yeah, but yeah, it's there's like a specific area where core committers discuss the values, topics that, you know, they are responsible for. And I do have access to that. And that's where, you know, discussion around which module is strategic to Drupal? Which one? No, you don't the fundamental capabilities that can I've seen these happening.

Nic  
Okay, I have one final question for you before we close out the show as we're coming up on time. So feel free to feel free to be brief here. But as we've been talking to us, I've been curious, do you think that there's going to be a new, like, right now we have an experimental module process like you can, if you have a module want to get into core, you can make it if you do certain things, you can make it experimental. And then if you make it a stable release, after two , consecutive point releases, then it can become part of core, do you think that there's going to become a way to remove modules at a point release like that in the future? Like, rather than because right now, it looks like you're doing it at you know, when Triple 10 comes out, these things removed, winter 11 comes out, these ones are removed? Do you think that will also become a Hey 10.2, this is gonna be deprecated. In 10.4, it's gonna be removed? Or is it always gonna be a major point release where it gets removed?

Theodore  
So yeah, it's not going to be possible to do that in a minute because of semantic versioning. Because all the modules are part of the public API. So if you change the public API, if you remove things from your public API, you need to increase the major version for your application. Right? So you can add stuff in minor, but you can't remove stuff in minor, which is why we have all the BC layer that stays until the next major release, which is why it's good to have like regular majorities to get rid of all the PC the years that we accumulated.

Nic  
Makes makes perfect sense. Well, thank you for joining us. This has been really enlightening. I'm glad you reached out after the book module to provide some insider knowledge. So definitely appreciate that.

John  
Do you have questions or feedback? Reach out to Talking Drupal on Twitter with the handle TalkingDrupal or by email with a show @  talking drupal.com You can connect with our hosts and other listeners on Drupal slack in the Talking Drupal channel.

Nic  
You can also promote your Drupal community event on typing Drupal. Learn more about this the tukituki.com/tv promo,

John  
get the Talking Drupal newsletter for show news, upcoming Drupal camps, local meetups and more. Sign up for the newsletter at talking drupal.com/newsletter.

Nic  
And thank you patrons for supporting talking Drupal, your support is greatly appreciated. You can learn more by becoming a patron at talkingdrupal.com and choosing the become a patron button. Well, as I mentioned, it's been a pleasure having you on Theodore, if our listeners wanted to get in touch with you had some questions would be the best way for them to do that.

Theodore  
I think there's like Drupal Slack Channel in there or the contact form on drupal.org. It's no underscore the underscore is silent.

Nic  
And Tearyne, if our listeners want to get in touch with you.

Tearyne  
Yep. On drupal.org And on the Drupal slack I'm ninelivesblackcat, and on LinkedIn and Twitter I'm tearyneg.

Nic  
And John, how about you?

John  
You can find me on all the major social networks and drupal.org @ JohnPicozzi. And you can find out about EPAM at epam.com.

Nic  
And you can find me pretty much everywhere @nicxvan

John  
And if you've enjoyed listening, we've enjoyed talking. Have a good one, everyone.

Nic  
See you next week.

Theodore  
Thanks right