Moderated By: gaborhojtsy

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 other Monday at 20:00 CET / 14:00 ET.
➤ 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/3033833
➤*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 and tell us what you are here for.

gaborhojtsy Me! Gábor core committer
mikelutz Michael Lutz, migrate subsystem maintainer and core contributor. Here to keep Gábor Company.
gaborhojtsy haha :smile:
xjm xjm, release manager. Sorry I'm late; got distracted. :slightly_smiling_face:

1️ Let’s celebrate optional Twig 2 support landing in core! Yay! If we can figure out a way to do https://www.drupal.org/project/drupal/issues/3031639 then we can automate testing it for regressions. For now we do daily retesting in https://www.drupal.org/project/drupal/issues/3032695 in a hackish way :smile:

gaborhojtsy this is currently postponed on https://www.drupal.org/project/drupal/issues/3020303 where I don’t think there was a conclusive answer yet? /cc @catch
xjm I think about 75% of folks have had "that's too dangerous" and 25% have said "well maybe"? I wonder if we could summarize the pros and cons better to come to a decision?
xjm But https://www.drupal.org/project/drupal/issues/3020303#comment-12956199 summarizes the plan from a process standpoint
gaborhojtsy @xjm yeah I think further feedback from @catch et. al. there would be great
gaborhojtsy for twig 2 the daily RTBC retest is a sensible workaround for now
gaborhojtsy but its not scalable :smile:
xjm catch was one of the people we discussed #34 already. Though I should have documented who participated in the discussion, oops.
andypost @xjm it just not clear for people what brings and what could be broken.
gaborhojtsy @xjm oh, right, I had the inclination to move it to 8.8 but no such option yet haha :smile: too late here :smile:

2️ We did not move a lot on the Symfony 4 front since the last meeting (https://www.drupal.org/project/drupal/issues/2976394), but there is some light in the tunnel

gaborhojtsy https://www.drupal.org/project/drupal/issues/3031577 was committed briefly that would have allowed us to commit two issues to resolve many fails there but then it got rolled back with some issue that was not 100% clear to me /cc @alexpott
mikelutz I’ve been working on https://www.drupal.org/project/drupal/issues/3033120 a bit, but I think we may end up wanting to revert https://www.drupal.org/project/drupal/issues/2937542 which will be a setback
gaborhojtsy @mikelutz hm, sad
mikelutz I’m pretty sure I can fix it, but I really feel like’s it’s more redoing it than a legitimate followup.
gaborhojtsy it looks like this will not be instant for sure, so it should be rolled back
gaborhojtsy ok let’s do this I’ll roll back
mikelutz Well, whenever it gets reverted, I’ll rebase and re-roll and move the work back over to the main issue. Hopefully we can get it back in quickly.
mikelutz Sounds good, thanks.
gaborhojtsy done, pushed, will post on the issue now
gaborhojtsy done that too
gaborhojtsy it is pushed (https://cgit.drupalcode.org/drupal/commit/?h=8.7.x&id=4837822141aa46b457...) but did not show up on the issue, well, at least I moved it back to NW

3️ Deprecation tooling. @mglaman built the drupal-check tool that wraps phpstan as a phar executable, its very cool: https://github.com/mglaman/drupal-check

gaborhojtsy @mglaman also built https://deprecationbot.glamanate.com/ which has all the core modules and some contribs
gaborhojtsy I was looking at integrating into testbot as well on d.o as a validation step since that would allow us to scale this to all d.o projects and do some reporting on d.o, but I only got to setting up a local testbot so far :smile:
gaborhojtsy with some help from @mixologic

4️ @berdir, @andypost et. al. have been working hard on entity deprecation issues, introducing trigger_error()s, a nice win over the weekend was https://www.drupal.org/node/3028656

gaborhojtsy It looks like they got a good handle on the organization of the patches, with ongoing issues like https://www.drupal.org/project/drupal/issues/2974253#comment-12975357
gaborhojtsy I just reviewed this one ^^
gaborhojtsy plenty other actions at https://www.drupal.org/project/issues/search?issue_tags=%40deprecated
andypost also RTBC https://www.drupal.org/project/drupal/issues/2811749 from you mindmap)
gaborhojtsy @andypost that looks good indeed

5️ I moved the deprecation format consistency issue to “needs announcement for final discussion” which MAY signal to the coding standards maintainers to announce that it needs final discussion, leave it at that for two weeks and then if agreement is reached, announce it. Please don’t use the new format yet (as I have seen some people jumping the gun). https://www.drupal.org/project/coding_standards/issues/3024461

xjm We are on this step:
xjm > The coding standards committee use their discretion to decide which and how many of the "needs announcement for final discussion" issues to announce and tag with "final discussion".
gaborhojtsy yup!
xjm I will ping effulgentsia and ask about this issue
gaborhojtsy eg. @andypost started adopting it but it should not yet be adopted
andypost yep, it needs more automation, the main painpoint is codesnippet which most of time does not fit into 80 chars, specifically for service injections
xjm Those are supposed to be exempt from the line length rule
xjm Certainly not in the passing core ruleset
berdir not sure I get the don't use this format yet. the main difference seems to be drupal:8.0.0 vs "Drupal 8.0.0", and I've already had patches committed that use the machine name. and for constructors, we don't have a standard yet anyway..
gaborhojtsy @berdir interesting, what is the coding standard process for if we are sidestepping it?
xjm The main drawback of using the "new format" now is that we have a core standard already and we have not finalized the replacement
xjm Which means if committers accept the "new" format we might end up with 5 more variants on top of the 10 we already have :slightly_smiling_face:
andypost I bet we have more( the issue still needs better title and CR so could be ready to the time of new standard
andypost But it is really derailing to update deprecation messages for tons of patches when we have so many different examples in core
andypost One of annoying things is dot at the end of "see link"
gaborhojtsy @andypost yeah currently the examples at https://www.drupal.org/core/deprecation are the standard
gaborhojtsy I agree there should be one standard everywhere, but at least for now whatever you newly add or need to fix as part of a patch, applying the current standard is best
gaborhojtsy I looked into the phpcs rules patch and plan to update it later this week if I can :smile:
andypost @gaborhojtsy I know cos point people there at sprints and they disappointed this nits
gaborhojtsy @andypost you know I was working on fixing them and you also said fixing them outright would cause patch rerolls extensively though? was that not a negative remark then? :slightly_smiling_face:
andypost moreover `node/123.` will bite d-org when it will migrate to d8, because this links will be broken
gaborhojtsy hm, why?
xjm Right, the patch rerolls are why we schedule this for beta phase
andypost @gaborhojtsy because d8 does kinda `(\d*)` for `{node}`
andypost d7 is less strict on routing
gaborhojtsy hm, I don’t think that could be a problem, worst case, d.o can add path aliases,

6️ DrupalCon! I submitted daily BoFs to DrupalCon to cover Drupal 9 topics and plan to promote some Drupal 9 related sprint topics. So far not a lot in http://bit.ly/contribute-at-drupalcon-seattle, please sign up there :slightly_smiling_face:

gaborhojtsy Bof list at https://twitter.com/gaborhojtsy/status/1092928897698549760
xjm I think sprint tasks we can have are: (1) Continue finding missing change records for core. (2) Tooling! (3) Upgrading contrib for deprecations.
xjm I am hoping to schedule "update the deprecation messages" patches the week before DrupalCon (if we can get the phpcs rule done in time) but otherwise we should do thos eon Monday.
gaborhojtsy ideally that is 3 topics that we can write down leaders for in the sheet :slightly_smiling_face:
gaborhojtsy @xjm one thing I am wondering is the extent of attendance on contribution and overall on Monday
gaborhojtsy @xjm given sessions don’t start until 2 days later
gaborhojtsy I’ve been pushing the above spreadsheet to happen sooner than later so we can get some idea
gaborhojtsy this time I have a feeling Monday will be very sparsely attended
gaborhojtsy but happy to be proven wrong :smile:
xjm Yep, it might be like the extended sprints of old
mikelutz I’m flying in Monday and out on Friday, but I don’t know what my flight times are going to be yet. If I’m in early enough I’ll head to the convention center on Monday.
gaborhojtsy my Monday or Friday will be half day, currently thinking better arrive Monday afternoon than to split up Friday, but its crystal-balling really

Comments

Gábor Hojtsy created an issue. See original summary.

gábor hojtsy’s picture

Issue summary: View changes

justafish credited Berdir.

justafish credited xjm.

justafish’s picture

Issue summary: View changes
justafish’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.