Drupal 9 readiness meeting / 23 March 2020 [#3120130]

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

Hello and welcome to this Drupal 9 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 9 upgrade of their sites are also welcome.
➤ Usually happens every 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/3120130`
➤*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.

vuil	Ilcho :slightly_smiling_face: BG (edited)
Gábor Hojtsy (he/him)	Gábor, Drupal 9 coordinator
shaal	Ofer Shaal, Rector, Umami
hestenet (he/him)	Tim from the DA, Portland, OR - asynchronously following along today :slightly_smiling_face:
xjm	:wave: xjm, not on vacation, unlike @Gábor Hojtsy (he/him)
dww	Derek, core contributor
lleber	Luke - very minor contributor - just watching today.
catch	Nat, core committer.
Swati Chouhan	Swati, New in Contributor
drumm	Neil, Drupal Association
mixologic	Ryan, Drupal Association
xjm	Help triage the 9.0.x queue as per previous announcement :slightly_smiling_face:
xjm	Also, priority issues to try to backport before respective next releases on 8.7/8.8/8.9
Gábor Hojtsy (he/him)	@xjm I’ll assume you wanted to post those in 1️⃣ :slightly_smiling_face:
xjm	Oops sorry, too many threads
xjm	Hi, my name is "Help Triage"... is actually not that far off, darn :stuck_out_tongue:
larowlan	Lee late, lurking
dan2k3k4	Dan :wave:

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

vuil	Deprecation statuses, Rector, Drupal-check (phpstan) (edited)
xjm	Need someone to temporarily fix 9.1.x HEAD :wink: #3121799: Adjust fallback symlinking for semver
drumm	Enabling semantic versioning for contrib? https://www.drupal.org/node/1015226#semver-transition has a TODO in it.
Swati Chouhan	t calls() will be fix in drupal 9 release ?#3113904: [META] Replace t() calls inside of classes (edited)
hestenet (he/him)	Maybe doesn't need a topic - but just to make sure folks saw it -- drumm deployed this: https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...

2️⃣ Drupal 9 beta1 is released! :tada: (edited)

Gábor Hojtsy (he/him)	See https://www.drupal.org/blog/drupal-9-0-0-beta1
Gábor Hojtsy (he/him)	This means that June 3, 2020 will be the release date.
Gábor Hojtsy (he/him)	So we removed the alternate release dates from other areas of the site, eg. the Drupal 9 docs. (edited)
dww	Huzzah! :)
Gábor Hojtsy (he/him)	I added https://www.drupal.org/docs/9/install-drupal-9 for a short install doc, inspired by @alesr
Gábor Hojtsy (he/him)	Tried to link more general purpose docs.
xjm	https://groups.drupal.org/node/535846 also
Gábor Hojtsy (he/him)	=> 3️⃣
larowlan	Thanks to everyone who has made this happen

3️⃣ Drupal 8.9 beta expected this week

Gábor Hojtsy (he/him)	See https://groups.drupal.org/node/535846
Gábor Hojtsy (he/him)	Once this is out, Drupal 9.1 will be open for new feature development :slightly_smiling_face:
dww	Also 8.8.5, right?
Gábor Hojtsy (he/him)	8.8 and 8.7 bugfix releases should also be released soon, possibly this week
xjm	We might also just do next week since it's the normal patch window

4️⃣ What is left to enable semantic versioning for contributed projects?

Gábor Hojtsy (he/him)	@drumm raised this
dww	#3113992: The 'Update' page has no idea that some updates are incompatible should be committed and backported as far back as we want to say we support semver for contrib.
dww	AFAICT, everything else in core is now back to 8.8.x. I assume we're not going to backport any of the other semver/multi-core update manager patches to 8.7.x.
xjm	I think @catch specifically just asked not to do this yet to avoid potential regressions while handling the releases
drumm	Should I enable it for any projects on a one-off basis, for more real-world testing? I have someone asking at #2681459: Support contrib semver releases#comment-13520065
xjm	I think one-off requests is a good way to roll it out with less risk
catch	Yeah that seems good. I am mostly worried about just more stuff going on when there is already a lot going on.
Gábor Hojtsy (he/him)	@catch when do you think would be a good time to enable it later on?
drumm	And specifically, I’d like someone to update https://www.drupal.org/node/1015226#semver-transition to replaceIf your project supports Drupal 8.TODO or lower, don’t switch to semantic versioning.
xjm	Uh, 8.8.3 I guess?
drumm	May need to be 8.8.3 or lower / 8.9.something or lower, if there isn’t a clean cutover that covers all branches.
dww	Can y’all confirm we’re not going to backport any of that stuff to 8.7.x?
xjm	We discussed it previously and there was one issue that was dangerous to backport, so we stopped backporting them past 8.8
xjm	(I forget which)
dww	Also, should we bump prio on #3100386: Create contrib update module test cases that use semantic versioning ?
xjm	Done

5️⃣ 9.1.x HEAD tests are failing and you can help fix it :)

Gábor Hojtsy (he/him)	@xjm raised this, see #3121799: Adjust fallback symlinking for semver
xjm	So this needs an infra fix, but in the meanwhile we should skip the test
xjm	I do not know how to skip a Nightwatch test :wink: but it is in langcodeTest
xjm	Then we'd un-skip it once l.d.o is fixed
drumm	And it will intermittently fail at some point in the future, since it is also testing the internet and that service’s uptime.
drumm	Relying on the internet is a bad idea.
xjm	Yeah, we fixed some functional tests (that tested the internet and l.d.o) I think but not the Nightwatch one apparently (edited)
xjm	So it could also be fixed later to not test the internet, but in the short term we need HEAD to pass
drumm	Yep, I should be able to fix it in the next day or two.
lauriii	opened issue for removing the dependency on localize.drupal.org: #3122002: Remove dependency to localize.drupal.org on Nightwatch tests

6️⃣ State of Rector

Gábor Hojtsy (he/him)	@vuil raised this sort of :slightly_smiling_face: I broke his topics down
Gábor Hojtsy (he/him)	@shaal can probably explain what happened last week :smile:
shaal	@lleber it seems more specific to upgrade_rector module, and not Drupal-Rector itself, I suggest we continue this discussion outside of this meeting.
shaal	State of Rector -@Dan added entityManager deprecation@nerdstein has WIP for getMock() and db_query deprecations
shaal	We are looking for additional developers to join us to create additional Rector Rules (that thing that teach Rector how to fix a deprecation)
shaal	As well as receiving feedback from people who use Drupal-Rector on what we can change & improve
nerdstein	id love to see the full set of issues created for deprecations
nerdstein	i think it would be easier to socialize that work
shaal	I agree, I'll create it this week! (edited)

7️⃣ Help triage 9.0.x issues, and what version to use for which issues

xjm	So https://drupal.slack.com/archives/CDDD98AMN/p1584968173196000
Gábor Hojtsy (he/him)	@xjm posted this earlier:exclamation:Reminder about the 9.0.x issue queue :exclamation:Hi everyone! Just a reminder that the 9.0.x-dev version in the issue queue should only be used for:Major-only changes that are still allowed during the beta phase according to https://www.drupal.org/core/d8-allowed-changes#beta or a release management exception (beta targets).Bugs that only affect 9.0.x and higher.If the issue is only allowed during minor releases according to https://www.drupal.org/core/d8-allowed-changes#minor, it should be filed against 9.1.x-dev. If the issue is a bug that affects Drupal 8 too, it should be filed against 8.8.x-dev. Please don’t file any old issue against 9.0.x-dev and remember that you can test patches against any version regardless of what the issue’s filed against.
xjm	In general, if it's a change that's allowed only in minor releases, it should not be filed against 9.0.x. And if it's a bug, it should only be filed against 9.0.x if it does not exist in D8.
xjm	In general, file the issue against the lowest branch where it's allowed based on the change set
dww	That’s a bit of a departure from what we’ve been doing / saying for a while, no? My understanding is we were supposed to file stuff against the latest branch then discuss how far to backport.
dww	I’m totally down with the new proposal, but it seems we should document that somewhere other than this meeting and Slack threads, no?
catch	I always ask for patches against the latest branch, but it's OK for the issue to be against the lower branch. But yeah it's not been consistent.
xjm	@dww This has been policy since release
xjm	(of D8)
xjm	And is documented in the bulk update comments you all don't read :slightly_smiling_face:
xjm	@dww The backport policy says it's committed to the highest branch first, and so should be tested against the highest branch or have a patch available. This is not the same as the version selector.
catch	If the patch doesn't apply to all branches, we can commit to 9.0.x then work on a backport, but the issue can still be filed against 8.8 - just have to be careful with test runs.
xjm	Since we don't have branch labels in the issue queue yet, we've since Dec. 2015 documented that it should be filed against the lowest branch where the change is allowed... which is also why I am now surprised to @catch not making a strong statement one way or the other, lol
xjm	But the entire way we do bulk issue updates etc. is based around bugfixes allowable in the patch branch being filed against that branch, and minor-only issues being filed against that branch
catch	lol no I agree, just sometimes people mark issues needs work when there's no 8.8 patch, but I always prefer to get an RTBC patch into 9.0.x first.
xjm	Oh ah, no, I agree with that too. OK phew.
xjm	lol
catch	Sometimes when issues are against 8.8, people roll only 8.8 patches, and then they don't apply to 9.x, an you can't commit anything at all.
xjm	TLDR: Minor-only issues 9.1.x; bugfixes 8.8.x or 9.0.x depending on whether it's a regression in D9. And major-only issues 10.0.x. BUT most issues should be done in a minor with BC and deprecation; true major-only issues are rare and should only be implementing deprecation removals and dependency major updates.
xjm	There are several hundred more issues in the 9.0.x queue than there should be, so please triage accordingly. :slightly_smiling_face:
xjm	And remember, you can and should queue tests against other branches than the one the issue is set to!
dww	Thanks for clarifying, and sorry for my confusion on our policy.
xjm	@dww You are far from alone; otherwise I would have not had to bring this up at all :slightly_smiling_face:

8️⃣ Priority issues that you can help with to backport to 8.7/8.8/8.9 before their upcoming releases

Gábor Hojtsy (he/him)	@xjm raised this
xjm	If anyone can help with:
xjm	#2917600: update_fix_compatibility() puts sites into unrecoverable state backport NR
xjm	#3098475: Add more strict checking of hook_update_last_removed() and better explanation backport NR
xjm	#3104015: Replace ZendFramework/* dependencies with their Laminas equivalents 8.9 version NR
xjm	(As well as impact vs. disruption discussion; still need to decide whether to backport that)
xjm	And
xjm	#2989745: views_update_8500() inlines configuration changes instead of this being done on config save for bc
xjm	That last is not committed to any branch yet; there's some feedback that someone could address to move it along
xjm	Anyone have others? Othr than #3113992: The 'Update' page has no idea that some updates are incompatible which is RTBC and not on y'alls plate at present :slightly_smiling_face:
dww	I’ll open the doc-only follow up for 3098475
dww	#3121827: Documentation follow-up fixes for hook_update_last_removed() from #3098475

9️⃣ Projects’ Drupal 9 compatibility status

Gábor Hojtsy (he/him)	@vuil and @hestenet (he/him) raised this
Gábor Hojtsy (he/him)	@drumm rolled out https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%... which is the list of modules with at least one Drupal 9 compatible release (edited)
Gábor Hojtsy (he/him)	while the URL looks very funky, its just a filter with Drupal 9 compatibility on the module listing
Gábor Hojtsy (he/him)	https://dev.acquia.com/drupal9/deprecation_status has further compatibility data down to number of deprecated API uses
Gábor Hojtsy (he/him)	I worked on an updated version of that which will hopefully go live soon that also integrates data about explicit Drupal 9 compatibility and which errors are covered by Rector :slightly_smiling_face:
dww	See also #3121281: Add Drupal core compatibility info to release & project pages
Gábor Hojtsy (he/him)	@dww that would definitely be a very welcome addition
shaal	@Gábor Hojtsy (he/him) This is a simpler version of the same url you shared above -https://www.drupal.org/project/project_module?f[3]=sm_core_compatibility:9 (edited)
Gábor Hojtsy (he/him)	@hestenet (he/him) is this true that 936 modules would support Drupal 9?
drumm	936 of them have signaled they work with their .info.yml files.
vuil	Yes, I see 936 in a post of hestenet (he/him):https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%... (edited)
Gábor Hojtsy (he/him)	@drumm I assume this is taken with “at least has one info file that is Drupal 9 compatible”
drumm	Only the “primary” info file is checked. If there is a match for {project_short_name}.info.yml, that’s used. The fallback is to use the one with the shortest number of characters.
Gábor Hojtsy (he/him)	ok, I coded a “number of extensions == number of info files with Drupal 9 compatibility” for the dev.acquia.com tool but I will go and revise it to be in line with this
Gábor Hojtsy (he/him)	sounds great
drumm	Yeah, with Composer, it is probably best practice to stop stuffing multiple modules/themes/etc into a single project. (But if they are already there, keep them where they are for continuity.)
Gábor Hojtsy (he/him)	yup
Gábor Hojtsy (he/him)	Posted this based on the above: https://twitter.com/DropIsMoving/status/1242189954911961093?s=20
berdir	With drupal9 beta, all .info.yml files in a project must be d9 compatible or you get a parse error. when through 10+ over the weekend to get our project to install again
berdir	and one project = one module is not maintainable, try splitting up something like commerce, also there are test modules, like the 50 or so test modules that webform has :wink:
Gábor Hojtsy (he/him)	yeah my dev.acquia.com source data was indicating more like 559 drupal.org projects explicitly Drupal 9 compatible if all sub modules are required to be compatible with 9.x (edited)
Gábor Hojtsy (he/him)	that said, I don’t think test modules are expected to have that, but did not yet manage to dig deeper
berdir	it's tricky. they're not necessary for a regular install because our hard filter of tests directories ignores them. but try having a single kernel test in a project, and things wil go boom :slightly_smiling_face:
berdir	also, dev.acquia.com source data is stable releases, there are lots of dev releases out there. but d.o isn't complete either, I would definitely expect pathauto to be in there, which has a partially compatible release and fully compatible in dev, same for ctools, that also has the definition. (edited)
Gábor Hojtsy (he/him)	@drumm ^^ here are some examples that are missing :slightly_smiling_face:
Gábor Hojtsy (he/him)	@berdir well, dev.acquia.com also has dev releases, 2359 of them https://dev.acquia.com/drupal9/deprecation_status?name=-dev&result=&erro...
berdir	yeah, but only if there is no stable release :slightly_smiling_face:
drumm	Pathauto is there, https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...
drumm	As is Chaos tools, https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...
berdir	ok, then the sorting is the problem? those two should be in the top 3 based on installations?
drumm	The “most installed” sort is counting number of installs for the versions that are compatible. Which is from the old “views is most installed, but it isn’t even a D8 module” type of problem
berdir	ok
drumm	So if it is dev-only, only installs -dev count, for example.
berdir	I see, yea I thought I already had the key in pathauto 1.6, but apparently not. everything cleared up then
Gábor Hojtsy (he/him)	@drumm is there a d.o api version of this list so I can grab it for my processing script and correlate / augment the data from the all contrib runner? (edited)
drumm	There is not, checking the compatibility takes a bit of processing, so it is only in the search index. Didn’t see a need to put it in a field.
Gábor Hojtsy (he/him)	hm, ok
Gábor Hojtsy (he/him)	I think #3121281: Add Drupal core compatibility info to release & project pages would need it on a field in some way
drumm	The search indexing is very blunt, much less detailed than what that issue is looking for. It is only indexing “has some release compatible with some release of Drupal 9”. This keeps the search forms pretty straightforward.

🔟 Fixing all the t() calls in classes

Gábor Hojtsy (he/him)	@Swati Chouhan raised this
Gábor Hojtsy (he/him)	specifically #3113904: [META] Replace t() calls inside of classes
Gábor Hojtsy (he/him)	I don’t know if there is anything stopping this from being fixed in minor releases, I suspect it does not need to be done for Drupal 9.0 itself, unless its not possible in minor releases.
xjm	So this kind of change is a cleanup task, not tied to any particular major version.
xjm	Note that the issues should not be filed per-module
xjm	Rather per base class
xjm	If the service is already available, then the issue is backportable because that makes other backports less likely to diverge. However, injecting a new service is a minor-only change that should be done with BC in the constructor (an optional argument and triggering a deprecation error in the case where the new service is not set)
xjm	This is another reason that it's important to scope it per base class, because a given module will have many classes that have the service and others that don't :slightly_smiling_face: