Drupal 9 readiness meeting / 20 April 2020 [#3127261]

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 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/3127261`
➤ *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.

dww	Derek, core contributor (usually Oakland, CA, but I’m “stuck” in Hawaii these days). (edited)
kristen_pol	Kristen from California, USA :wave:
Neslee	Neslee from India
johnwebdev	John from Sweden
hestenet (he/him)	Tim from the DA, in Portland, OR
longwave	Dave from the UK
tedbow	Ted, from Acquia, Ithaca, NY, USA
jungle	Jungle from Chongqing, China
nerdstein	Adam, from Acquia, Pennsylvania, USA
dan2k3k4	Dan, Zurich
shaal	Ofer Shaal, Drupal-Rector & Umami (Florida :sunglasses:)
Gábor Hojtsy (he/him)	Gábor, Hungary
pingwin4eg	Mike, Ukraine
vuil	Ilcho, South East Europe
xjm	ohai, xjm, release manager in Wisconsin
catch	catch, core committer, joined late.
mixologic	Ryan, also late,
heddn	Lucas, very late

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	Curious if there is a way to see core commit credits like drupalcores.com for D9, etc. I made this issue :https://github.com/lauriii/drupalcores/issues/131but maybe drupalcores.com isn't the right place for this?
dww	Is there a way to mark specific deprecated code paths as “it’s cool, we know what we’re doing, please stop warning about it?” Like a comment standard that tells Drupal-check to ignore? I’ve got various contribs with fallback code to still work on 8.7.0. They keep getting flagged and “helpfully” patched by eager contributors and robots. (edited)
xjm	We have less than two weeks to the beta deadline -- identify beta target issues that are not eligible for RC from the meta #3110198: [META] Beta targets following Drupal 9.0.0-beta1 and 8.9.0-beta1 and issue tag. Triage here?
Gábor Hojtsy (he/him)	@xjm I posted that as 2️⃣ we can break it out to multiple topics if needed
xjm	Separate: #3108658: Handling update path divergence between 11.x and 10.x
xjm	Another separate topic: I glimpsed a thread the other day about needing to downgrade postgres requirements potentially? @daffie @catch @Gábor Hojtsy (he/him)
shaal	Status report for the following projects -Drupal-Rector , upgrade_status, upgrade_rector
catch	@xjm that was sqlite I think? #3107155: Raise SQLite version requirement to 3.26 in Drupal 9
nerdstein	is there any overall update around semantic versioning?

2️⃣ RC week is two weeks from now, beta targets to be worked on now :slightly_smiling_face:

Gábor Hojtsy (he/him)	#3110198: [META] Beta targets following Drupal 9.0.0-beta1 and 8.9.0-beta1 is the current focus issue
nerdstein	did you mean beta2?
Gábor Hojtsy (he/him)	well, those were following beta1 :slightly_smiling_face:
nerdstein	got it, ok
xjm	Here is a queue: https://www.drupal.org/project/issues/search/drupal?project_issue_follow...
xjm	We should go through all of them
xjm	And then these bugs:
xjm	#3100712: Drupal 8.7.10 to 8.8.0 update fails if views have invalid configuration
xjm	#3118625: Migrate sets revision_translation_affected incorrectly when different languages co-exist for 8.x un-translatable fields
xjm	#3120910: Sites with missing schema information can't update to 8.8.3+ - attempts to run all historical updates
xjm	Anything that's related to a dewpendency change should have a beta deadline -- maybe we should go through and tag beta deadline issues from the beta targets. @catch thoughts?
xjm	#3118726: Upgrade to js.cookie 3#comment-13537374 maybe deserves discussion. This should probably be beta-deadline, but OTOH we are waiting on their stable release
catch	@xjm so patch and minor updates I think we should commit until the rc - especially since that's the last chance to do them outside patch releases of 8.9. js.cookie 3 seems to be the only one that's a 'proper' update - do you mean beta deadline for beta2 for that one?
xjm	Oh oops I guess I mean RC deadline
xjm	Sorry for the confusion
xjm	So the RC deadline is May Day... or let's say April 30 actually
xjm	Ten days from now
xjm	It's not looking super probable that js-cooke 3 will be stable by then -- but what if it comes out in May? They don't have a plan to support old majors
catch	I was wondering if we'd even want to update to the rc now.

3️⃣ Status of PostgreSQL version support

Gábor Hojtsy (he/him)	@xjm raised this, cc @daffie and @catch
xjm	Anyone have a link for this? I lost track
Gábor Hojtsy (he/him)	#3118455: [META] Create contrib fallback database driver for PostgreSQL 9.6
Gábor Hojtsy (he/him)	both #3110803: Allow contrib modules to run the tests for Drupal core would be needed on drupalci for that to work
xjm	So is this only blocked on CI? Is the core blocker resolved for separate contrib drivers?
Gábor Hojtsy (he/him)	My understanding is it is only blocked due to lack of CI support (edited)
catch	the pgsql contrib driver has a stable release now, it just doesn't get DrupalCI testing yet.
catch	Also effulgentsia posted a patch to try to hack drupalci.yml to make that work in the interim.
catch	#3128699: Testing issue for pgsql_fallback
mixologic	Okay, so we determined that we are not going to be able to support running contrib db drivers on drupalci in any sort of reasonable timeframe, and that contrib db drivers can and should just test themselves using travis and running the specific db tests.
mixologic	(I didnt look at effulgentsia’s patch yet though)
xjm	So then should we have issues in the contrib projects' queues, not infra queues, to set up travis testing?
mixologic	I do have a higher level question though: does this actually block us from changing the requirements? What Im seeing is that the rationale for this requirement is that “some people cannot upgrade to a compatible version” and that is true for the changing php requiremnts, the changing mysql/mariadb requirements etc. Why is this specifically an issue?
catch	I don't think it blocks us no - the drivers are extremely thin wrappers around the core drivers so they don't really need patch testing yet or anything.
xjm	Yeah that's sorta the meta question. We already raised the core requirements, but did so based on the plan to allow contrib fallbacks to lower versions
xjm	It's more a should-have for that reason
mixologic	But yes, the fallback driver for mysql (mariadb?) I think already has a travis setup. I think these are nice to haves.
catch	It should block committing any patches that use features not supported by the contrib versions (i.e. that would require an update to a contrib driver), but there are probably two or three of those.
xjm	We should find and explicitly postpone those isssues
mixologic	Okay, I was getting a little worried about needing to downgrade postgres requirements potentially
catch	Just did that with #2988018: [PP-1] Performance issues with path alias generated queries on PostgreSQL
mixologic	Cool, so even though the requirements are technically raised, the old versions of the db’s will still work until such time as we leverage new features of the new versions.
mixologic	Whoa, wait, drupalci support or contrib drivers having a travisci test?
catch	@mixologic so you can't install with the old versions, but the contrib drivers literally only lower the version requirement.
catch	@mixologic edited the comment.
Gábor Hojtsy (he/him)	@mixologic yeah we don’t yet leverage the new features but raised the requirements to not work on (soon) unsupported versions.
Gábor Hojtsy (he/him)	this way we can also add new capabilities that leverage those features in 9.1 onwards if we want to
mixologic	Right. Im just cautioning that core development not be blocked on any drupalci promises - thats vaporware and I dont know when it wont be.

4️⃣ Contrib porting going well :slightly_smiling_face: 1325 projects are compatible already!!!

Gábor Hojtsy (he/him)	list at https://www.drupal.org/project/project_module?f%5B0%5D=&f%5B1%5D=&f%5B2%...
Gábor Hojtsy (he/him)	I think we can clearly say that is unprecedented 44 days out of a stable release of core :slightly_smiling_face:
Gábor Hojtsy (he/him)	Almost half of the top 200 projects are also compatible, see https://dev.acquia.com/drupal9/deprecation_status/graphs for more aggregate data

5️⃣ Make your first Drupal 9 compatible releases to make me donate more € to the Drupal Association

Gábor Hojtsy (he/him)	I’ll donate 9€ for each newly Drupal 9 compatible release up to €900, see http://hojtsy.hu/drupalcares-9
Gábor Hojtsy (he/him)	Today @Ron Northcutt jumped in to double the budget to €1800!!!
Gábor Hojtsy (he/him)	Which is likely needed given the speed this was going :slightly_smiling_face:
Gábor Hojtsy (he/him)	There were already 20 releases in the first 2 days https://twitter.com/gaborhojtsy/status/1251539436770340864?s=20
Gábor Hojtsy (he/him)	I also published the script I am using to track when you are releasing a newly Drupal 9 compatible release :smile: https://github.com/goba/new_drupal9_projects
Gábor Hojtsy (he/him)	Note that our €1800 will be matched by @Dries and go up to €3600 in total unless the DA fundraiser goes about 100k dollars until end of April.
kristen_pol	When/where will it be announced that @Ron Northcutt is doing that? I didn't notice a tweet about it yet

6️⃣ Status of drupal-rector and upgrade_rector and upgrade_status (edited)

Gábor Hojtsy (he/him)	@shaal raised this :slightly_smiling_face:
Gábor Hojtsy (he/him)	I published a demo video of the two upgrade_* modules last week at http://hojtsy.hu/blog/2020-apr-16/upgrade-status-april-2020-update-and-i...
nerdstein	continued working on my blog post
shaal	We released Drupal-Rector 0.4.0 (edited)
shaal	https://github.com/palantirnet/drupal-rector/releases/tag/0.4.0
shaal	Summary of the release:Upgraded to latest Rector (version 0.7.x)Added CI test using Github ActionsAdded new Rector rules for the following deprecations:format_dateUnicode::strtolowerFILE_CREATE_DIRECTORYFILE_EXISTS_REPLACEDrupal::l()drupal_render()drupal_render_root()
nerdstein	@shaal are there key issues that would help us hit a higher percentage?
shaal	@nerdstein We're running through this list:https://dev.acquia.com/drupal9/deprecation_status/errors
shaal	I think we finished more than half of the first page
nerdstein	@Gábor Hojtsy (he/him) could we enhance that page to show which have rector rules?
shaal	@Gábor Hojtsy (he/him) do you know when will the graphs & data get updated for the latest rector coverage?
nerdstein	@shaal where did you leave off?
shaal	@nerdstein we are still actively working on it
nerdstein	im finding this hard to track :joy:
Gábor Hojtsy (he/him)	@nerdstein https://dev.acquia.com/drupal9/deprecation_status/errors?message=&projec...
Gábor Hojtsy (he/him)	(already done :P)
nerdstein	beauts
Gábor Hojtsy (he/him)	@shaal the d.o system runs it every week 1am Saturday, then I parse it in the next week, it is currently showing the data from the 17th, new data will be available on the 24th again
shaal	Do you manually parse the rector index file? or were you able to automate it? (edited)
Gábor Hojtsy (he/him)	@shaal I would not automate it, I need to do a couple manual steps anyway, it does not take a lot of time, I took the one new rector from last week into the script in https://git.drupalcode.org/project/deprecation_status/-/commit/cbd6f9573...
Gábor Hojtsy (he/him)	so the current data is represenatative of rector coverage as in dev :slightly_smiling_face:
shaal	We are planning to publish a blog post on how developers can levarage Rector, and release technical documenation about each Rector rule that was created.
Gábor Hojtsy (he/him)	Yay thanks @shaal
shaal	Wea are planning to publish a blog post on how to contribute to Rector, including a detailed walkthrough video of building a Rector rule from scratch. (edited)
Gábor Hojtsy (he/him)	BTW Dries was testing both upgrade_status and rector over the weekend, which I know because he found a glaring bug in upgrade_status and contributed a rector rule :wink:
shaal	:grin:
shaal	New additions to the mothership project Rector , are now being tested against drupal-rector to make sure nothing breaks.
Gábor Hojtsy (he/him)	@shaal woah that is cool :slightly_smiling_face:

7️⃣ Handling update path divergence between 8.9.x and 9.x (edited)

Gábor Hojtsy (he/him)	@xjm raised this
Gábor Hojtsy (he/him)	#3108658: Handling update path divergence between 11.x and 10.x
xjm	So the questions here are:
xjm	Is this the right approach?
xjm	2. Where do we document it?
xjm	3. Can we add a test enforcing the policy?
pingwin4eg	Alternative way is to start every hook_update_N function body with a condition, checking whether the current data model already has necessary changes.
catch	The one thing that would really help here for tests would be using build tests for upgrade path testing. Then we could test from every patch version of 8.8 and 8.9 to 9.0 including interim updates potentially.
catch	Probably this issue is the closest: #3082230: [meta] Convert some tests to Build tests
xjm	@timplunkett (he/him) ^ Related to your work sorta?
xjm	I'
xjm	will tag the meta beta target
catch	Apart from being able to test a two-step upgrade (from 8.8 to 8.9, then to 9.0) there's not really a way to test this. Unless we re-dumped database dumps every time we add 8.9 or 9.x hook_update_N()
catch	I really think we just need to not add any 9.x-specific hook_update_N() for as long as possible.

8️⃣ Is there a way to mark specific deprecated code paths as “we know what we are doing”

Gábor Hojtsy (he/him)	@dww raised this
Gábor Hojtsy (he/him)	Like a comment standard that tells Drupal-check to ignore? I’ve got various contribs with fallback code to still work on 8.7.0. They keep getting flagged and “helpfully” patched by eager contributors and robots.
Gábor Hojtsy (he/him)	As much as possible, I tried to make the deprecation status info trust the maintainers :) eg. https://dev.acquia.com/drupal9/deprecation_status token has 4 deprecated API uses or metatag has 5 but we just display as green/compatible
Gábor Hojtsy (he/him)	because the maintainers said so
xjm	This is also relevant maybe to the work @tedbow is doing for providing contrib upgrade patches
Gábor Hojtsy (he/him)	I believe upgrade_status should be doing the same ATM
tedbow	Yeah not sure how drupal rector will handle this yet.
tedbow	but I think might something if someone wants to run drupal-rector themselves they could configure
Gábor Hojtsy (he/him)	@dww I don’t know how could comments mark stuff as such, you may be calling deprecated things, extending deprecated things, etc.
nerdstein	is this like an ignore directive?
dww	I've seen various comment conventions in other projects for things like "coding-standards-ignore". I was hoping for something similar here.
dww	Case in point: if (floatval(\Drupal::VERSION) >= 8.8) { return \Drupal::service('entity_display.repository') ->getFormDisplay($entity_type_id, $bundle_id, $form_mode); } // This is fallback code for 8.7.x and below. It's not called on later // versions, so we don't nee to "fix" it for upgrade_status. return entity_get_form_display($entity_type_id, $bundle_id, $form_mode);
dww	I want the comment to not just (try to) alert human contributors, but to tell drupal-check and upgrade_status that this is not an error to "fix".
dww	Perhaps @shaal can weigh in here?
Gábor Hojtsy (he/him)	@dww would that have a @start_ignore_deprecated and @end_ignore_deprecated? How would it look like for certain things like extending a deprecated base class or invoking a deprecated method, etc.Also who is available to implement parsing it for phpstan, rector, etc? :slightly_smiling_face:
xjm	We should probably post an issue to discuss this in the queue
shaal	I can investigate more regarding Rector abilities to ignore specific lines.In the meantime - all rector rules are grouped by the drupal version that introduced that deprecation. I'm not sure if it's applicable here, but we can direct it to run certain set of rules, without deprecation in 8.8 for an example.
nerdstein	is this a rector requirement or a drupal-check requirement?
dww	Which queue? I can open an issue if I know where. ;)
Gábor Hojtsy (he/him)	@nerdstein sounds like it would be an improvement for both
nerdstein	ok - good to know
mirom	Also who is available to implement parsing it for phpstan, rector, etc?It was just added to the latest release of phpstan
Gábor Hojtsy (he/him)	@mirom what exactly?
mirom	https://twitter.com/ondrejmirtes/status/1252115874317832193?s=21
Gábor Hojtsy (he/him)	hm, how that work withclass Foo extends DeprecatedBar
Gábor Hojtsy (he/him)	would putting @phpstan-ignore-next-link in the docblock right before it silence it?
Gábor Hojtsy (he/him)	@dww what do you think?
dww	That’s super exciting, thanks! I agree this won’t solve everything, but it’d totally help in the example I pasted above.

9️⃣ Do we have insight into commit credits specifically for Drupal 9?

Gábor Hojtsy (he/him)	@kristen_pol raised this
Gábor Hojtsy (he/him)	I don’t know exactly how we did this for Drupal 8 or previous minor releases where we did
Gábor Hojtsy (he/him)	I think @timplunkett (he/him) had some methodology / scripts?
timplunkett (he/him)	I have scripts that parsed the issue queue for specific tags/components. it was very manual to compile
xjm	@lauriii owns the Drupal8cores repo/namespace, but it's all in Ruby and frontendy scary things
kristen_pol	It would be wonderbar to have something on drupal.org that showed any version and specific versions but maybe that's asking too much :slightly_smiling_face:
xjm	There are two data sourcesx: parsing the commit credit like D8 cores does, and the actual issue credit meta-data has saved on Drupal.org. (edited)
kristen_pol	Sideways related, I've seen commit credits given without issue credits and vice versa (both accidents). It would be nice if there was a more consistent way to do these
kristen_pol	Like automatically give issue credit if a commit credit is added (doesn't help the reverse, obviously)
xjm	That usually happens for one of two reasons: either the committer who is committing the patch didn't previously review it(So they get issued credit but are not on the message), or there was a cross post for error when committing. (edited)
kristen_pol	Right
kristen_pol	I know we don't want to check the issue credit for everyone automatically but what about people who RTBC? (like adding a file) Or will that be too abused?
kristen_pol	That would help a little with forgetting to check the issue credit box for code reviewers (edited)
xjm	We have have a detailed policy for this
xjm	@kristen_pol https://www.drupal.org/core/maintainers/issue-credit
xjm	@kristen_pol Tried briefly for it to be the other way around, with people automatically checked, but it worked very badly. So we switched it back. It is on the maintainer to ensure that issues are credited fairly.
xjm	In general, if the credit on D.O is wrong, one should simply ask the committer to correct the issue credit
kristen_pol	I know it's not easy to do right/fairly. I'm only one data point but I saw two times in one week that I didn't get credit for one or the other even though the intention was there so I'm assuming it's a fairly common thing based on my small sample size. I normally don't pay too much attention to it but I've given myself a goal of 100 core credit by DrupalCon so I'm paying attention :wink:
xjm	Reverting to change the message is messy, but re-saving the credit is simple.
xjm	@kristen_pol If it happens, just ping the person who committed it :-)
kristen_pol	Right, I did get the issue credit fixed. Agree that the core credit is not easy
xjm	@kristen_pol For the most part Corps commuters are very practiced and thoughtful about who is credited. Can't speak for contrib, but we do suggest following core's policy. (edited)
kristen_pol	Yeah, they know. It was a mistake, which happens. Just wondering if there were easy things to make it less error-prone
kristen_pol	Right, I'm mostly focused on core ATM
kristen_pol	But similar issue applies
hestenet (he/him)	@drumm or I could potentially work up a query - if we had a well-designed description of what data we want to be looking at.
kristen_pol	Well, IMO, since the commit credit and issue credit don't always match up, I'd take the union of both :slightly_smiling_face:
xjm	@hestenet (he/him) Maybe we could add that as a could-have for the Drupal.org changes for D9? On the issue

🔟 Update on semantic versioning

Gábor Hojtsy (he/him)	@nerdstein raised this
Gábor Hojtsy (he/him)	From what I’ve been seeing looking at releases every day now the uptake has been very good.
Gábor Hojtsy (he/him)	a lot of new releases appear to be semantic
nerdstein	ok, is there an ultimate date to move projects? is this only a responsibility of the maintainer?
Gábor Hojtsy (he/him)	no date, no
Gábor Hojtsy (he/him)	there is no need to move anything
hestenet (he/him)	IIRC (and I may not) - it might become a hard D10 requirement?
nerdstein	got it
hestenet (he/him)	If we eventually phase out info.yml in favor of the composer.json stuff instead
nerdstein	that would be a big discussion
catch	Core doesn't actually care if a module has a version or what the version is at least outside of update status.
Gábor Hojtsy (he/him)	@catch hm, does it not stop you from installing modules that are incompatbile?
Gábor Hojtsy (he/him)	module list UI and form, validation, etc.
drumm	Update status has been the main core thing for support - being able to do the version comparison on all of major/minor/patch, and being able to check status for semver modules when the 7.x/8.x was previously part of the updates.drupal.org path.
Gábor Hojtsy (he/him)	Uhm, right, incompatibility is not dependent on project version, these are apples and oranges, sorry :smile:
catch	@Gábor Hojtsy (he/him) the compatibility isn't encapsulated in the version though.
drumm	Sites have run modules/etc not from Drupal.org, for custom site-specific stuff, etc, presumably with all sorts of version numbering standards. Works okay, just the update status wouldn’t work just as well.
catch	Right site-specific modules and git checkouts are versionless too.

1️⃣ 1️⃣ Potentially lowering the SQLite requirement

Gábor Hojtsy (he/him)	#3107155: Raise SQLite version requirement to 3.26 in Drupal 9
Gábor Hojtsy (he/him)	@catch raised this, cc @xjm
catch	Personally I think it's OK to leave as is, given the new Ubuntu LTS is coming very soon. This means a short window for existing Ubuntu LTS users where running sqlite is tricky, but it's a dev-only dependency.
catch	Release is in three days: https://www.omgubuntu.co.uk/2019/10/ubuntu-20-04-release-features
catch	The issue is that existing LTS users don't get prompted to update until the first patch release, which is July. But that's still only a month after 9.0.0
mixologic	huh. that issue summary is weird.
mixologic	oh I see. #96 onward

1️⃣ 2️⃣ Drupal 9 release celebrations!

Gábor Hojtsy (he/him)	@dan2k3k4 set up #d9launch for gathering interested people to help set up a website, social streams, etc.
Gábor Hojtsy (he/him)	we are brainstorming there and he started working on the site
Gábor Hojtsy (he/him)	@zelfje signed up to help with the on-the-day livestreams
Gábor Hojtsy (he/him)	we need more people involved in this :slightly_smiling_face:
Gábor Hojtsy (he/him)	if you don’t have that much time but can help spread the word, signing up at https://twitter.com/drupal/status/1247488922856366082 and spreading that would be really useful too