Drupal 10 readiness meeting / 12 October 2020 [#3176493]

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 18: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/3176493`
➤ *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.

Gábor Hojtsy (he/him)	Heyo, Drupal 10 coordinator here :slightly_smiling_face: (edited)
Kristen Pol (she/her)	Kristen, contributor, Central California :wave:
Neslee	Neslee, contributor :wave:
shaal	Ofer, Drupal Rector, Umami demo
andypost	Andy, contributor
catch	Nat, core committer.
mixologic	Ryan, DA Represent!
mikelutz (he/him)	Hello all
greg.1.anderson	g1a @ sf
AlexMazaltov	alexmazaltov contributor
kimb0	Kim, Sydney Au,

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

Kristen Pol (she/her)	https://drupal.slack.com/archives/C392CHBEW/p1602184977192300
Kristen Pol (she/her)	Update on d9readiness stuff ^

2️⃣ Drupal 9.1 alpha patch deadline is this Friday, are you working on stuff for this release that need help or reviews?

mirom	there is some list of issues seeking for help - https://twitter.com/nevergonehu/status/1314500509093560321?s=20
Kristen Pol (she/her)	@mirom Are those D10 readiness related? I looked at 3 of them and it wasn't obvious to me
Kristen Pol (she/her)	Oh, I was in the wrong thread. These are for 9.1. Sorry for the noise
andypost	Here's a policy about changes for alpha https://www.drupal.org/about/core/policies/core-change-policies/allowed-...
andypost	@mirom I will review history patch, quickly skimmed and found few nitpicks with comment-history injection
mirom	Thanks Andy, not my issues, I just noticed them :slightly_smiling_face:
Kristen Pol (she/her)	I added this to Twitter to see if there are other issues people are hoping to get in: https://twitter.com/kristen_pol/status/1315720189309145088?s=20
catch	#3113400: Deprecate more jQuery UI library definitions would both be nice to get into 9.1.x if we can.
Kristen Pol (she/her)	@andypost Did you mean to change the status to RTBC for #3110972: Update easyrdf library to 1.0.0?
greg.1.anderson	I am hoping to address my review feedback for #3135247: Composer's "prefer-stable" setting cannot be relied on to produce a stable release today; after that is ready, I will need someone to review again and hopefully re-rtbc
andypost	@Kristen Pol (she/her) @catch easyrdf looks ready and now has BC
AlexMazaltov	#2671162: Also use text editor (CKEditor) for "summary" of a text field seems it RTBC
mirom	I don't think #2671162 is a good idea, because a lot of people rely on summary containing no html, so it's kinda breaking bc. Any ideas?
mirom	never mind, commented on the issue

3️⃣ CKEditor 5

Gábor Hojtsy (he/him)	Work (re)started on #2966864: Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10
Gábor Hojtsy (he/him)	it may be a bit confusing because the latest work is on the issue fork
Gábor Hojtsy (he/him)	it also has a patch from more than a year ago
Gábor Hojtsy (he/him)	(which is outdated)
Gábor Hojtsy (he/him)	the issue fork has the branch that is being worked on https://git.drupalcode.org/issue/drupal-2966864/-/tree/2966864-ckeditor5...
Gábor Hojtsy (he/him)	You can collaborate on the issue fork:

4️⃣ PHP 8 support

Gábor Hojtsy (he/him)	Landed almost all the internal issues, see #3109885: [meta] Ensure compatibility of Drupal 9 with PHP 8.0 (as it evolves)
Gábor Hojtsy (he/him)	just updated the issue summary to be current
Gábor Hojtsy (he/him)	PHPUnit 9 is RTBC, and would solve half the dependency problems #3127141: Use PHPUnit 9 for PHP 7.4+, while keeping support for PHPUnit 8.4 in PHP 7.3
Gábor Hojtsy (he/him)	It is highly unlikely that we can be PHP 8 compatible in time, but if we can land our own issues and our dependencies other than phpunit are not major version updates then we MAY BE able to get PHP 8 compatibility out in a patch release, but that is a lot of MAY BEs :smile: (edited)
andypost	git log of PHP-8.0 branch (created few days ago) shows that RC2 on Wed will bring more incompatibilities because it full of "Improve parameter names in ext/*" so there will be few days to address changes
Gábor Hojtsy (he/him)	So more likely that 9.2 would be the earliest to be PHP 8 compatible at this point. That said, steps towards that would still be useful
andypost	Yep, because few dependencies still need hacks (edited)
andypost	But it would be great to bump composer dependencies before beta
Kristen Pol (she/her)	There seem to be several more issues tagged as PHP 8.0 than are noted in the meta. Are any of these important? https://www.drupal.org/project/issues/search?issue_tags=PHP%208.0
Gábor Hojtsy (he/him)	Not all of those are core issues and some of those are about supporting new PHP 8 features (eg. named arguments) at places.
Gábor Hojtsy (he/him)	The priority is to make Drupal 9 run fine on PHP 8. Supporting new PHP 8 features would come after that :slightly_smiling_face: (edited)
andypost	I just checked - after composer update 2 packages gone from why-not php:8phpspec/prophecysymfony-cmf/routing Gonna file upgrade issue
Gábor Hojtsy (he/him)	Yay! (edited)
andypost	Filed patch #3176504: Upgrade dependencies prior to 9.1.0 (edited)
hussainweb	Will there be a problem if just the parameter names have changed, not the signature? It’s not like we use named parameters anyway.
andypost	@hussainweb there's signature changes (good news is not a lot), renaming is totally fine.
hussainweb	I’m expecting the RC2 build should be out by Thursday or so. I’ll try out my regular manual testing steps to see what happens.
andypost	RC2 uploaded https://downloads.php.net/~pollita/
andypost	List of argument changes looks complete https://github.com/php/php-tasks/issues/23

5️⃣ Contrib Drupal 9 compatibility

Gábor Hojtsy (he/him)	@Kristen Pol (she/her) raised this
Gábor Hojtsy (he/him)	https://dev.acquia.com/drupal9/deprecation_status has current stats :slightly_smiling_face:
Gábor Hojtsy (he/him)	from the 9th of October at this time
Gábor Hojtsy (he/him)	there is now almost 4100 projects compatible with Drupal 9
Gábor Hojtsy (he/him)	I personally emailed all 9 remaining projects in the top 200 this week :smile:. Got 4 new D9 compatible releases, so we are down to 5 incompatible in the top 200
Gábor Hojtsy (he/him)	We also emailed 2k project maintainers a month or so ago. It is hard to measure the effect of that in isolation. I used my newly D9 compatible release script and counted that in the 10 days prior to that email and the 10 days after there was a 13% increase in the daily rate of newly Drupal 9 compatible releases. So not a break-through but some bump-up at least. (edited)
Gábor Hojtsy (he/him)	Screenshot 2020-10-12 at 20.52.49.png
Gábor Hojtsy (he/him)	graphed are days of september ^^^
Kristen Pol (she/her)	Interesting. Any plans for a repeat email blast at some point?
Gábor Hojtsy (he/him)	I would love to do more targeted reaching out, the personal top 200 reaching out worked, almost half the projects emailed got a release out :slightly_smiling_face:
Gábor Hojtsy (he/him)	That cannot be replicated for 2k projects though :smile:
Gábor Hojtsy (he/him)	If someone would be interested to write a script with the d.o API, it would be interesting to collate the sponsoring organizations of the projects / people maintaining the projects that are affected.
Gábor Hojtsy (he/him)	Then we can possibly reach out to those organizations to see if they can focus on this a bit / see their name on up to date projects, rather than not up to date ones :)
Gábor Hojtsy (he/him)	I did not have time to implement this, but it should be possible with the d.o API and the list we already have on dev.acquia.com
Kristen Pol (she/her)	That's a great idea. I haven't done any scripts yet so I'm not sure how to start with that. Or I could spend a couple hours clicking through them and create a list. :) For that, it would be super helpful if there was a direct link from the deprecation status tool to the project pages. (edited)
Gábor Hojtsy (he/him)	The summary data for all projects is https://git.drupalcode.org/project/deprecation_status/-/blob/8.x-3.x/dat... which is a standard CSV file, you can filter it down to projects with only info change, order by usage, etc. Then use an excel/google sheet formula to produce a link from the project name and viola :slightly_smiling_face:
Kristen Pol (she/her)	Oh! That's great:) I'll see if I can do that this week
Gábor Hojtsy (he/him)	Superb, thanks
Kristen Pol (she/her)	I've started the spreadsheet here and shared it with you. I'll manually grab the organizations next. https://docs.google.com/spreadsheets/d/1qIS8vt0MCP9aqNaLpH-T96sAh8MwqvF1...
Kristen Pol (she/her)	I'm filling in the organization, last committer, and last commit date/time. I've done a few but, before I continue, let me know if you think anything else would be useful while on I'm on the project page
Gábor Hojtsy (he/him)	That is great wow.
Gábor Hojtsy (he/him)	Thanks so much!
Kristen Pol (she/her)	Sure! Are those columns sufficient? If so, I'll keep working on it over the next few days
Gábor Hojtsy (he/him)	I think so. We can reach out to the organizations at least where we have some personal connection then.
Kristen Pol (she/her)	Sounds good!
Kristen Pol (she/her)	Ok, I did 100 with the most usage: https://docs.google.com/spreadsheets/d/1qIS8vt0MCP9aqNaLpH-T96sAh8MwqvF1...
Kristen Pol (she/her)	I think that may be all I have in me for awhile
Kristen Pol (she/her)	You have edit rights so you should be able to add columns or whatever
Kristen Pol (she/her)	One organization with a LOT of modules was https://www.drupal.org/connect-i
Kristen Pol (she/her)	Lots with "Opigno" as part of the project name
Kristen Pol (she/her)	Let me know if you have any questions or need help with something
Kristen Pol (she/her)	I had a bit more energy so I filled in the supporting organizations for the next 100... I'm all done in there... if you want to share the doc with anyone, that's fine as long as they are comment-only. Thanks
Gábor Hojtsy (he/him)	Superb thanks! I'll start emailing them later next week. :)

6️⃣ Composer 2!

Gábor Hojtsy (he/him)	Drupal 9.0.7 was the first Drupal core release packaged with Composer 2.tgz/zip packages are created with composer to support people starting off with them but figuring out they need to move to composer. Drupal 9.0.7 was the first to be packaged with composer 2, instead of composer 1. (edited)
Gábor Hojtsy (he/him)	So that means Drupal core is generally fine with composer 2 apparently :slightly_smiling_face:
Gábor Hojtsy (he/him)	there is #3135247: Composer's "prefer-stable" setting cannot be relied on to produce a stable release that @greg.1.anderson is working on though but that is not blocking using composer 2
greg.1.anderson	Moving from composer/semver^1 to composer/semver^3 is going to be interesting, because composer/composer:^1 can't use the later, and composer/composer:^2 can't use the former. This is only for requiring these Composer projects as dev components of the drupal/drupal project from the git repository. I think that using Composer 1 or Composer 2 from the commandline will continue to work after we do that upgrade. I'm just concerned there might be some API differences in composer/semver:^3 that might make it hard for us to go up and maintain b/c. Have not tried / investigated yet, though.
greg.1.anderson	I'll look at it after that other issue is merged
Gábor Hojtsy (he/him)	Hm, that may get interesting, yeah.
greg.1.anderson	The current patch is asking for composer/semver ^2, so it's not pulling in composer 2 any longer. I'll make a comment on the issue.#3128631: Update dependencies composer/composer ^2 and composer/semver to ^3
mixologic	composer/semver doesnt have too many major breaking changes between 1/2/3
mixologic	https://github.com/composer/semver/releases/tag/2.0.0
andypost	Thanks @greg.1.anderson it's clear that we need 3.0.0 at least for php8 https://github.com/composer/semver/releases/tag/3.0.0 (edited)
mixologic	https://github.com/composer/semver/releases/tag/3.0.0
andypost	btw depending on version of composer (1 or 2) I'm getting different plugin-api-version, @greg.1.anderson please elaborate it for #3128631: Update dependencies composer/composer ^2 and composer/semver to ^3#comment-13855698 (edited)
mixologic	So, we dont use ConstraintInterface, nor EmptyConstraint, and dont rely on . as a version anywhere, so 3.0 is clear. For 2.0 we dont use AbstractConstraint and whatever impact the master/trunk/default change has is virtually minimal due to master/trunk/default not being a standard branch name that anybody uses on drupal.org / contrib.
mixologic	i.e. our internal usage of semver is very minimal, and thus we’re compatible with all 3 versions.
andypost	Then ^1\|^2\|^3 looks right fix, just not clear which composer should be used to create next patch)
mixologic	It seems to me our only requirements for composer/composer in core for core development are minimal (we use it in a script/plugin to determine which version of composer is running) As well as all the plugins themselves, but those were all updated to composer 2 as well.
mixologic	Im thinking we could also bump "composer/composer": "^1.9.1", in /composer.json to ^1.9.1 \|\| ^2
andypost	that's what last patch doing, I just missed 3.0 of semver and plugins api
greg.1.anderson	We only need composer/semver ^1 \| ^3
greg.1.anderson	composer/semver ^2 is my fault and should not exist.
greg.1.anderson	I thought that composer/composer:^1 worked with composer/semver ^2 so I asked for a stable release of composer/semver, thinking it would unblock our Composer-as-dev-dependencies work ahead of the Composer 2 release. Alas, I didn't confirm this, they made the stable release and it didn't help us. They later needed composer/semver ^3 for a late breaking change.
greg.1.anderson	So ^2 only existed for a short period of time.
greg.1.anderson	I guess there's no harm in ^1 \| ^2 \| ^3 if it works, but are we ever going to test ^2? If not, maybe just leave it out.
andypost	@greg.1.anderson do you mean we should add a test that ensures that core works with ^2? (edited)
greg.1.anderson	I would think that if we required composer/semver ^1\|^2\|^3 then there should be a test for ^2. But that's probably not the case for every required major version of every dependency in our composer.json, so maybe it's not necessary. But if we've never had a ^2 test and we don't need ^2 support, maybe it's clearer to omit it.
greg.1.anderson	(From the requirement)
greg.1.anderson	@andypost ^^

7️⃣ Symfony 5/6

Gábor Hojtsy (he/him)	all the new problems @mikelutz (he/him) identified with Symfony 5 are now fixed
Gábor Hojtsy (he/him)	so its back to issues with Mink only to be compatible with 5
mikelutz (he/him)	I did not attempt to reach out to the mink maintainer yet, He appears to be quite active in symfony and github, but also maintains a ton of projects, so hopefully just needs to be poked to merge a fix for mink.
Gábor Hojtsy (he/him)	Symfony 6 is at #3161889: [META] Symfony 6 compatibility
andypost	The last leftover in SF5 is backport of site.path, which looks should be marked wontfix #3074585: [Symfony 5] Replace app.root and site.path string services with container parameters#comment-13834263 (edited)
Gábor Hojtsy (he/him)	the SF6 one is promising as well, issues need to be broken out to commit 1-1 (edited)