Drupal 10 readiness meeting / 31 January 2022 [#3259002]

Meeting will happen in #d10readiness on drupal.slack.com.

Hello and welcome to this Drupal 10 readiness meeting!

This meeting:
➤ Is for core and contributed project developers as well as people who have integrations and services related to core. Site developers who want to stay in the know to keep up-to-date for the easiest Drupal 10 upgrade of their sites are also welcome.
➤ Usually happens every other Monday at 19:00 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to: `https://www.drupal.org/project/drupal/issues/3259002`
➤ *Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

0️⃣ Who is here today? Comment in the thread below to introduce yourself.

shaal	Ofer Shaal :blob_wave:, DrupalPod, Umami
hestenet (he/him)	Tim from DA here to keep an eye on what's up :slightly_smiling_face:
catch	Nat, only partially here atm.
longwave	Dave, core contributor
andypost	Andy, contributor
xjm	:wave: xjm, core release manager
Gábor Hojtsy (he/him)	Gábor, Drupal 10 coordinator :slightly_smiling_face:
larowlan	Lee, vendor of bespoke hats for small dogs
kimb0	Kim, cloff prunker
xjm	Australians, man. Never know what is going to come out of their mouths, or even what just did. :stuck_out_tongue:
quietone	Vicki, Playcentre mum and migrate maintainer
Björn Brala (bbrala)	Late, but hi! Iso audit preparer and Jsonapi maintainer
Kristen Pol (she/her)	Kristen, California, contributor, catching up
Ilcho Vuchkov (vuil)	Ilcho Vuchkov (vuil), Bulgaria EU
dww	Derek, US, late
Aaron McHale	Better late than never I guess, Aaron, procrastinating :smile:

1️⃣ Do you have suggested topics you are looking to discuss? Post in this thread and we’ll open threads for them as appropriate.

hestenet (he/him)	Not sure it really needs a thread - but from a DA infra point of view - last week fixed some packaging issues with the alpha release - and are now focused on fixing some random fails in d9/d7 private (security) testing.(you already know this Gábor but for the benefit of others..) We did get the project_analysis job for d10 running on php8 and all that to help catch deprecations, but it too seems to have some sort of random fail. It's the first thing on the list after the two testing issues above.
xjm	One thread for PHP 7.3 deprecation in D9
xjm	Another for the PHP requirement announcement schedule, PHP 8.1 tracking issue.
xjm	A third for the general process issue for dealing with EOL PHP versions.
xjm	Recommendations for the next things to focus on before alpha2: CKE5, SF6, non-critical PHP 8.1 bugs, #3257127: Trigger a deprecation message when a deprecated module or theme is enabled,
larowlan	Progress update on removing modules from core

2️⃣ Drupal 10.0.0-alpha1 is out now! Based on Symfony 5.4 this is aimed at testing for deprecated APIs against these major dependency updates. (edited)

Gábor Hojtsy (he/him)	Thanks to all contributors :slightly_smiling_face:
Gábor Hojtsy (he/him)	https://www.drupal.org/project/drupal/releases/10.0.0-alpha1

3️⃣ Drupal 10 now accepts deprecated code removals and it is happening at quite a pace already, thanks all!

Gábor Hojtsy (he/him)	@andypost has been championing this :slightly_smiling_face: #3213895: [META] Remove deprecated classes, methods, procedural functions and code paths outside of deprecated modules on the Drupal 10 branch is the META
dww	Sweet. This is always a fun round of core development.
andypost	Actually I stuck on views clean-up and whole box of worms #2902895: [meta][no patch] Replace uses of REQUEST_TIME and time() with time service
andypost	Request time replacements has serious impact on performance
longwave	Will help out with this where I can
Gábor Hojtsy (he/him)	@andypost if it becomes a performance problem, we may want to revisit that decision…
andypost	No need, better to finish conversion, otherwise core have no chance to #2218651: [meta] Make Drupal compatible with persistent app servers like ReactPHP, PHP-PM, PHPFastCGI, FrankenPHP, Swoole
andypost	It just need to find solution for cache layer usage, having calls to service inside of loops is bottleneck (edited)
catch	I'm down to a couple of fails on #3261486: Remove core updates added prior to 9.3.0 and adjust test coverage. This should unblock various deprecated code removals.

4️⃣ Updated all-contrib deprecation testing tool

Gábor Hojtsy (he/him)	As mentioned by @hestenet (he/him) the DA worked on updating the tool to run on PHP 8 and with Drupal 9.4.x
Gábor Hojtsy (he/him)	While there seem to be some (random?) fails, and job 74 keeps running from 6 days ago (you may want to halt that @mixologic?), good news is job 75 ran fine and seems to have produced complete results :tada: https://dispatcher.drupalci.org/job/project_analysis_d10/75/
Gábor Hojtsy (he/him)	I parsed that in and this produced a lot of new non-rectorable issues (5.6k non-rectorable deprecated API uses versus 1k previously when the checking was against 9.2.x).
Gábor Hojtsy (he/him)	If drupa-rector would cover drupal_get_path(), file_create_url(), render(), file_url_transform_relative() and file_save_data(), that would cover almost 4k out of the 5.6k deprecated API instances found. I submitted #3261614: Cover top Drupal 9.3.x/4.x deprecations and discussed with @mglaman that he may be able to look into this on Wednesday on his stream :slightly_smiling_face:
mglaman	I’ll work on these on Wednesday. I think these 5 should be easy
mglaman	compared to the PHPUnit stuff
mglaman	Oh, this is going to be a PAIN to deal with in Rector, but phpstan-drupal it should be “easy” https://github.com/mglaman/phpstan-drupal/issues/315
mglaman	It’d be nice to have a policy that any runtime deprecations need a phpstan-drupal ticket filed with the draft change record.
mglaman	Because PHPStan wouldn’t be able to pick this up on its own
Gábor Hojtsy (he/him)	Ah we discussed a policy similar to that on suggestion from @shaal a year back or so…
Gábor Hojtsy (he/him)	Cannot find the issue right now
shaal	@Gábor Hojtsy (he/him) was it this one?#3228433: [policy, no patch] Add a more integrated process for adding rector rules for deprecations
Gábor Hojtsy (he/him)	Hm yeah that was it but that is not quite about bringing phpstan to the table. So this would be its own thing.
Kristen Pol (she/her)	At this point, do you have a gut feeling if the automated tool coverage will be similar, better, or worse than for D8=>D9?
Gábor Hojtsy (he/him)	I think its still better than it was for D8 to D9 and with the 5 global functions it will be again leaps and bounds ahead :slightly_smiling_face:
mglaman	I'd say similar. There will be plenty of gaps and folks will assume the tools discovered or fixed more than they assumed. But hopefully better because everyone is more accustomed to the tools
mglaman	Like the fact not calling accessCheck on content entity queries was deprecated. Impossible to Rector beyond adding a comment. Pain on my end for detecting in phpstan-drupal
Kristen Pol (she/her)	Awesome, thanks!

5️⃣ Deprecating PHP 7.3 in Drupal 9

Gábor Hojtsy (he/him)	@xjm suggested this topic (edited)
xjm	The issue where this is being discussed is #2917655: [9.4.x only] Drop official PHP 7.3 support in Drupal 9.4 -- I just finished a big rewrite of the IS and filed numerous followups/related issues.
xjm	We could use review there of both the proposal in the MR, and the various discussion points listed out in the comments that are under the remaining tasks.
xjm	I also could use review on a small related bugfix that we could fix first (just string/URL fixes): #3261611: Fix PHP requirements link and standardize the strings that reference it
Gábor Hojtsy (he/him)	Reviewed this later one, just one minor comment :slightly_smiling_face:
xjm	@Gábor Hojtsy (he/him) Replied. TLDR it's on purpose and out of scope I think. :slightly_smiling_face:
Gábor Hojtsy (he/him)	ok, commented there

6️⃣ PHP 8.1 tracking and generally PHP requirement announcement schedule

Gábor Hojtsy (he/him)	Suggested topic by @xjm
xjm	This is what the committer team plans to announce:
xjm	We need to make a decision on PHP 8.0 vs PHP 8.1.Our commitment is to give organizations 5 month notice so they have time to plan. This results in the following possibilities:- Scenario 1's release date is June 15. It is already less than 5 months before June 15. Therefore, if we ship on June 15, it will be with a PHP 8.0 requirement.- Scenario 2's release date is August 17. If we release on this date, we will have communicated by March 17 if the requirement is PHP 8.1. If we have not communicated that before then, then the requirement will be PHP 8.0.- Scenario 3's release date is Dec. 14. If we release on this date, we will have communicated by July 14 if the requirement is PHP 8.1. If we have not communicated that before then, then the requirement will be PHP 8.0. (edited)
xjm	I'm drafting a core blog post announcement with that schedule. It will also include a CTA asking people to provide data about their hosts in #3261443: [tracking issue] Track hosting provider support for PHP 8+. Please help update the HSP support info for PHP 8.0 and 8.1!
xjm	For context, the previous commitment we made was to announce the final PHP requirement "several months before beta1", but that is ambiguous and no one other than core contributors would really know what that means.
xjm	We could also use help gathering data on ecosystem usage of various PHP versions (from Packagist, d.o, distros, etc.) in the parent issue of #3223435: Track PHP 8.1 support in hosting and distributions
Aaron McHale	Part of me is just like, screw it, go with 8.1, take advantage of all the nice things right out of the box (attributes, fibers, ec). D9 will go EOL end of 2023, that'll give roughly a year and a half of overlap (assuming a June release), more than enough time to upgrade to PHP 8.1. For a lot of people upgrading PHP versions is as quick as installing a new package, or updating a Docker image, or selecting 8.1 from a dropdown in cPanel or Plesk.
Aaron McHale	Those graphs from Packagist are really interesting, but I think the picture they paint is more about what the minimum version of PHP that people are running, not whether they could upgrade, because let's be honest, unless something like Drupal forces people to make the switch, most just won't.
xjm	"Screw it" is unfortunately not an approach we can take for whether it's possible to upgrade to D10 before D9's EOL because of people being blocked on distros/HSPs, etc. :slightly_smiling_face:
Aaron McHale	Yeah, I think I'm just being overly optimistic :smile:

7️⃣ General process for dealing with EOL PHP versions

Gábor Hojtsy (he/him)	Suggested topic by @xjm
xjm	Issue for this is #3223443: [policy, no patch] Process for dealing with EOL PHP versions during the Drupal 10 and future release cycles -- the scope is what to do with EOL versions after 10.0.0 (not to be confused with what to do specifically with 7.3 in 9.4, which needs to be less disruptive and finalized/announced ASAP).
xjm	Toward the end there I added a table of one proposed process for what our target for each of the PHP constants should be for each release of core
xjm	There's a few other things we'll need to define in the policy, including what to do if a dependency actually drops support for 8.0 or 8.1 or whatever before Drupal 10's planned EOL. Please review/discuss!

8️⃣ What are the best next things to work on in Drupal 10 core before alpha2?

Gábor Hojtsy (he/him)	Thread suggested by @xjm
Gábor Hojtsy (he/him)	#3257127: Trigger a deprecation message when a deprecated module or theme is enabled would help us move forward with deprecating core extensions
Gábor Hojtsy (he/him)	2. #3215044: Promote the non-stable statuses in admin/appearance page, optionally even visually would allow us to start deprecating themes!
Gábor Hojtsy (he/him)	3. CKEditor 5 stability could use some help. See #3238333: Roadmap to CKEditor 5 stable in Drupal 9 but best to coordinate in the #ckeditor5 channel.
Gábor Hojtsy (he/him)	4. Symfony 6 compatibility has outstanding issues, see #3258380: [Symfony 6][Second try] A number of methods of the class Drupal\Core\TypedData\Validation\ExecutionContext are considered internal and Drupal should not override them.
Gábor Hojtsy (he/him)	5. There is a set of non-critical PHP 8.1 bugs, see https://www.drupal.org/project/issues/search/drupal?project_issue_follow...…]10.&version%5B%5D=any_9.&issue_tags_op=%3D&issue_tags=PHP+8.1
murilohp	Hey! I hope it's not too late to join this thread, I have these two issues focused on database requirements for drupal 10, hope it fits on this topic:[#3214922]Thanks!
xjm	Both good candidates!
murilohp	Great!
Kristen Pol (she/her)	https://twitter.com/kristen_pol/status/1488361990670073856?s=20&t=sBgRHG...

9️⃣ progress update on removing modules from core

larowlan	We have an issue for tracker @naveenvalecha has started on patches
larowlan	@Spokje is tracking well with quickedit
larowlan	We need an issue to start removing forum
larowlan	Ditto rdf
larowlan	Ditto hal
larowlan	Should we have separate issues to deprecate them? One per module? Or one issue for the lot
xjm	Each issue requires a product decision, so one per
xjm	Also might have separate contrib maintainers, etc.
xjm	All the issues should be filed as children of #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1 and added to the IS there under the relevant section
xjm	Aggregator is the most critical #3188549: [Meta] Tasks to deprecate both Aggregator and our dependency on Laminas Feed because we can remove Laminas dependencies entirely when that's gone. (We already deprecated Diactoros.)
larowlan	The product decisions have been made in the ideas queue
larowlan	So can we jump straight to 'deprecate x' issues
larowlan	Then separate issues for 'remove x' in d10
xjm	Yep, that works
larowlan	Cheers, should have time for this on friday
xjm	I was going to say we should also deprecate REST, as JSON:API is the intended replacement for it, but maybe we can't do that until we've addressed all the things that JSON:API doesn't expose yet. (Menus, dblog messages, whatever. Etc.)
larowlan	We haven't had a product discussion around rest yet
larowlan	But we could open something in the ideas queue
catch	It's explicitly documented for JSON:API that it won't handle things like login. Maybe we need to split out and deprecate all the entity stuff in REST, leaving just those endpoints.
catch	https://www.drupal.org/docs/core-modules-and-themes/core-modules/jsonapi...
Björn Brala (bbrala)	Yeah jsonapi wont do login.@xjm would be interesting to know what endpoints are missing. I don't really remember an issue in the queue discussing that
xjm	@Björn Brala (bbrala) I just knew about dblog messages offhand because the JS Admin UI initiative floundered on the shores of that not being exposed via JSON:API (alongside other things like how to handle user login, forms, etc.). And menus because the Decoupled Menus initiative started out proposing a JS package but then ended up with proposing a new core API or module.So it's an interesting thing to consider in the long term. JSON:API is the best practice, but it can't do everything REST can, so we have two sort-of-redundant APIs in core. (Similar I guess to Field Layout and Layout Builder: Layout Builder doesn't do form layouts like Field Layout does, but it is superior in all other respects.) Probably not something we can address by D10.
larowlan	#3261652: Deprecate Forum module in Drupal 10
Björn Brala (bbrala)	Yeah d10 is not feasible at all :) But I think it ia something we want to track
larowlan	:dancergunterpenguin: its happening #3261652: Deprecate Forum module in Drupal 10 is RTBC
dww	I gotta carve time to get QuickEdit 1.0.0 out, and try to help with Tracker 1.0.0, too...
larowlan	trying to get some help at work to do ban and aggregator too
Aaron McHale	That is great news! forum holds a special place in my Drupal-shaped heart, and if I had more time I would volunteer to co-maintain it.
larowlan	If I had time I'd rewrite it as a react app using json API to reboot innovation on it
Björn Brala (bbrala)	That would be so cool :)
Aaron McHale	One thine that could be done to forum which would be a nice addition is the use of the new bundle classes
dww	There’s already an issue for that. :wink:
Björn Brala (bbrala)	Would be weird, extract the module from core then suddenly it get maintainer again hehe
Björn Brala (bbrala)	Maintained*
xjm	I mean, that's actually not infeasible. Having stuff in core is a tradeoff -- more contributors, but slower test run times and stricter standards. When we moved jQuery UI Datepicker into contrib before 9.0.0, it picked up a contrib maintainer fairly quickly.
xjm	Not a core contributor reluctantly providing sec releases to get the thing out of core, but an actual person who cared about it
Björn Brala (bbrala)	Yeah, I can see that that might happen for some modules. The barrier to get features or improvements into core is quite a bit higher.
dww	Not a core contributor reluctantly providing sec releases to get the thing out of core... resemble that remark. :wink:
Aaron McHale	This is an interesting discussion point, if more modules lived in contrib instead of core, and core was basically just the equivalent of the minimal install profile, then maybe a lot of core modules which (as xjm noted) don't get much attention, would actually get more attention. It hasn't really been possible to do that before, but with package_manager coming, there's no reason that, for instance, the standard profile, couldn't just composer require a bunch of (former) core modules from contrib. It also opens up the conversation around being able to install distributions (like commerce kickstart) directly from the installer.
Aaron McHale	Heck standard could even just be a separate project on D.o!
Aaron McHale	Don't know about anyone else, but I find the idea of a leaner core, quite appealing, but maybe that's because I spend most of my Drupal time in very custom distributions that all started from the minimal profile. Probably, half of the modules shipped with core are never installed in these cases.
dww	Were you around for the “small core” movement / debate? I could dredge up some issue nids about it if you don’t know what I’m talking about... (edited)
Aaron McHale	I might have seen one or two of those issues, while I've been a D.o member for 10+ almost 13 years, I only really got properly active in the community in the past 4/5 years, until then I passively dipped in and out of issues occasionally and was just a consumer of contrib. (edited)
catch	This from ten years ago is still relevant (both because it's a good blog post, and because a lot of the issues are still the same) https://www.lullabot.com/articles/understanding-8-where-drupal-is-and-wh... (edited)
Aaron McHale	That's was really useful read @catch thank you. I was looking forward to also reading "In his 8/31 blog post, Nathaniel Catchpole addressed this issue by naming five distinct layers of the Drupal software stack, and I think they're a great way to break things down." but it seems that link is now dead. (edited)
Aaron McHale	Scanning the D9 core modules list, and considering what will be removed in D10, it's actually now a fairly well balanced list of modules I would say. So perhaps the discussion has shifted, since compared to the early days of D8, we've come a long way in terms of removing and adding relevant/irrelevant modules from core.
Aaron McHale	As mentioned earlier, with things like package_manager coming, that also shifts the discussion a little, in the sense that we will have the technical capabilities to install extension from D.o in the background. So the idea that we could provide more installation profiles in the installer (like commerce) which showcase specific ways you can use Drupal, maybe even a blog/personal site focused one. It allows us to showcase even more of Drupal's capabilities and make it easier to get started with these types of sites, without necessarily needing to add all of these things to Core.
Aaron McHale	Building on the idea of those different layers of Drupal: What I think would also be interesting, is if I'm working on a particularly bespoke profile/distro, if I could composer require just base layers (core/lib/Drupal and the necessary scaffold files), but then separately composer require only the core modules/themes that are needed. Essentially taking what we have right now one step further, and essentially having the option to break out drupal/core-recommended into it's individual components. To be clear, I'm not explicitly advocating that we should do that, but it's an interesting thought that may be worth further exploration.
catch	@Aaron McHale my blog is long dead but the article is on archive.org (did the same thing)
Aaron McHale	@catch Thank you, that was also an interesting read.
larowlan	you may also like this core idea and if you're looking for some pre-umami ranting on the matter. i.e this has been an ongoing issue for 10+ years
larowlan	we've been busy treading water
larowlan	catch++ :heart: that post First, framework vs. product is a false dichotomy. Drupal core is both a crap framework, and a crap product, either of them on their own would have died a very quick and lonely death some time ago.