Moderated By: gaborhojtsy

Hello and welcome to this Drupal 9 readiness meeting!

This meeting:
➤ Usually happens every other Monday at 20:00 CEST / 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!
➤ Meteting notes will be posted at:
https://www.drupal.org/project/drupal/issues/3019442
➤*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 are here for.

mikelutz Hi all, Migration sub-system maintainer here.
xjm xjm, core release manager
Nick Wilde Nick Wilde, Victoria BC :canada: , Lurking/keeping up with changes for contrib module reasons/etc.
gaborhojtsy Gábor Hojtsy, Drupal core product manager, happens to wrangle the issue tree about and communication about Drupal 9
starshaped Aubrey in Boston, Massachusetts. Just lurking here to keep up to date with what's going on, d9-wise!

0️ Dependency updates. Last meeting we agreed we want to push for Symfony 5 eventually in Drupal 9. Interim Symfony 4 support is already in the works but need more eyes.

gaborhojtsy See https://www.drupal.org/project/drupal/issues/2937984 for symfony 4
alexpott One of the pieces of work that we’ve not really scoped is places where we diverged from Symfony and the underlying Symfony class has changed. A big example of this is the container where Symfony uses hotwiring and private access by default. This is the opposite of Drupal and the way we have public services and access them everywhere via get().
alexpott So whilst we can make Drupal work with later Symfony versions the way we’re doing things is very different from how we would if we started today.
gaborhojtsy @alexpott is it possible to get several other pieces in in the meantime? is someone taking the lead on that?
alexpott Yeah we can start on this work but no one is actively scoping it or doing it (as far as I know). Sometimes a Symfony deprecation forces us to.

0️.1️ CKEeditor 5 would be so nice to support in Drupal 8 optionally and Drupal 9 onwards, but it does not seem realistic. Unless someone is very enthusiastic about it? :slightly_smiling_face: The end of life of CKEditor 4 may affect the EOL of Drupal 9.

gaborhojtsy CKEditor 4 is EOL in 2023 https://support.ckeditor.com/hc/en-us/articles/115005281629-How-long-wil...
xjm The conclusion we had in the core committer meeting is that D9 may need to be EOL in 2023 _regardless_ of CKEditor, if we're depending on Symfony 4 at that point. However, if we go to Symfony 5, then we need to worry about CKEditor 5 support.
gaborhojtsy well, at least not guaranteed for later
xjm And the other conclusion was that we want to just do a scope estimate of what CKEditor 5 _support_ would entail, and think about this for the D8 LTS if it's achievable. But probably wouldn't be a must-have.
gaborhojtsy Anyone enthusiastic about it? :slightly_smiling_face:
xjm Well we said we'd ask Wim to spend a day on it. I don't think we actually did that yet though. :slightly_smiling_face:
xjm So if someone else does in the meantime that's awesome.
mikelutz I’m enthusiastic about someone else doing it. :slightly_smiling_face: My javascript kung-fu is not the strongest.
gaborhojtsy Lol. It would be best if there would be more people other than Wim for the sake of both the project and Wim :smile:
mikelutz https://www.drupal.org/project/drupal/issues/2966864 Linking this for the transcript
gaborhojtsy I posted a summary at https://www.drupal.org/project/drupal/issues/2966864#comment-12888742
gaborhojtsy I also pinged the question to Wim, so it does not get forgotten :slightly_smiling_face:

2️ Docs! I started https://www.drupal.org/documentation/9 earlier today and will start to fill in with some useful content we already know. Would welcome people interested in filling the gaps, eg. wire in docs about depreciations, how to test for depreciated uses, an exact list of deprecated for Drupal 9 stuff, etc.

gaborhojtsy For now the entire content is in the above snippet :grin:
xjm Gotta say though the current content is pretty great :wink:
gaborhojtsy :smile:
gaborhojtsy Some of us are also working with Dries on a blog post about Drupal 9 based on the details we all discuss in these meetings (no surprises there :D)

3️ @internal vs final: https://www.drupal.org/project/drupal/issues/3019332 — should we be more explicit about what contrib should not be using for the sake of easier upgrade paths

xjm It's an interesting thought experiment, but I'm with Berdir on this one. And I don't consider it to be something that should be on the D9 roadmap.
xjm We can keep the discussion and tests ongoing but for me it's out of scope for D9's API policy. We have enough to do.
mikelutz Maybe something we consider deprecating extending certain classes in Drupal 9 and then mark them final in Drupal 10. I really do like the idea, but it seems controversial enough that I don’t think we can get consensus and give contrib enough warning before 9.0
xjm Yep, that's a fair way of looking at it
gaborhojtsy Either way we need tooling for contrib / custom code to tell if they are extending internal stuff alongside with tooling if they use deprecated. Both are critical for knowing where update pains may be.
xjm I think that would be a good separate issue to file, much higher-level
xjm And related to the ongoing meta to mark stuff explicitly as `@internal` when the policy implicitly says it is (which we've had as sprint fodder for a couple years now)
xjm Like the current meta is likely a blocker to making tooling surface it better
xjm (vs. programmatically interpreting a 50-entry policy `<dl>`)
Nick Wilde I like the idea and hate the idea. Like often I do extend classes for custom work that I know may change but I want future improvements most of the time. But mostly I'm vaguely against; _I like more choices, even if some are riskier_.
gaborhojtsy https://www.drupal.org/project/drupal/issues/2550249
mikelutz The flip to that is a lot of stuff that should probably in fairness to contrib be marked @api as well that isn’t.
gaborhojtsy @Nick Wilde the ultimate problem is *you* may like those choices but when sites use modules that liked those and then have the upgrade pains that we said they would not have is a problem :smile:
mikelutz It would be really nice to have everything marked for the LTS, it would feel like we had Drupal 8 finally buttoned up, lol.
xjm Actually for `@api`, we talked to Symfony about this a couple years back
mikelutz poetic, if not practical. :slightly_smiling_face:
Nick Wilde To be clear, for *contrib* I don't like blind extend. For custom only I'm talking about
xjm They eventually flipped their practice to focusing on marking `@internal` rather than `@api`, for the same reasons we did in practice: It's much easier to identify what's _not_ API than what _should be carved in stone_
gaborhojtsy for tooling, we have https://www.drupal.org/node/2811561 but I am not sure d.o testbot uses it? @mixologic
xjm The BC policy doc doesn't yet really account for this, but frankly we don't really use `@api` because honestly we need to support the whole surface. Especially with how Drupal's extended.
mikelutz And it’s much easier to remove an @internal than an @api.
mikelutz That’s true, by the numbers the doc says that most things not marked @api should be considered @internal
xjm Yep, removing `@internal` is analogous to increasing visibility which is an API addition. vs. reducing it (removing `@api`) which is a BC break.
xjm There's a different meta for specific `@internal` additions; trying to find it
xjm Dunno why it is not linked in the main policy issue
mikelutz So, my patches should use @internal a lot more than I do. I don’t use it much because I consider it implicit according to the BC docs.
xjm Understandable when core also doesn't comply with that yet :slightly_smiling_face:
xjm Oh it is linked: https://www.drupal.org/project/drupal/issues/2873395
xjm That's something that should probably go on the D9 meta if it's not there yet
xjm And something we'll want to really sprint on in Seattle for example. Good intermediate-level task to contribute to D9 readiness.
mikelutz So in that issue about final, I posted a patch that added a trait that triggered an error if you extended the class. I wonder if that triat or something similar might be still usefull in D8 for classes we intend to mark internal in D9.
mikelutz I guess it’s just marking things the policy already says are internal, so no need to trigger errors, I suppose. goes back to tooling.
xjm It could be a useful pattern, but we don't want to accidentally raise errors for internal things being used correctly by collaborators. OTOH it would help us get info on when things _shouldn't_ be `@internal`, but when that's "by breaking someone's stuff" we need to be careful :slightly_smiling_face:
alexpott The thing is with the final discussion is that there are patterns that people can use to compose their classes differently that make upgrading and maintenance easier. It’s just that we don’t recommend them or enforce them via final and the free-for-all means that popular modules extend internal classes all the time. If we want reliable unattended updates it feels like something has to give.
catch https://drupal.slack.com/archives/CDDD98AMN/p1544470744027800?thread_ts=... this sounds worth exploring.
xjm Yeah, a trait could be an opt-in on a case-by-case basis. If we went that route though I'd rather see that as something we optionally include in new code when appropriate. Easy to remove it later if someone files an issue saying "Let me use this thing". I'm not on board with it being anything we block D9 on though.
xjm People extending paramconverters is not what makes minor updates break people's sites

4️ The big semantic versioning question. Since last time we talked about this with the DA (@mixologic in particular) and apparently d.o will have issues on the composer facade if you have a 8.x-3.1 release and an 9.x-3.1 release, so d.o would need to ensure unique version numbers or ….. we would need to move to *also* support semantic versioning in 8 and then drop the major versions in 9.

gaborhojtsy What this could really use is someone to jump in and try to make Drupal core support both 8.x and 9.x extensions and/or extensions without compatibility version numbers.
xjm Including auditing core for all the things that might be affected e.g. update status/security update info/etc.
gaborhojtsy @mixologic and I started to look into what it would take for localize.d.o integration in 8 to drop the core compatibility in URLs and it works sort of (more server side verifications and changes required): https://www.drupal.org/project/drupal/issues/3016471
gaborhojtsy the same would need to be done for modules/themes/update.d.o integration, etc. as @xjm wrote above
xjm I wonder if useful content for the D9 page or a child thereof might be "top things we need help with from contributors", which would include this, the `@internal`, Symfony, CKeditor, etc. And/or something like the 'sprint' tag for this initiative (which would be combined with the current tag for another Kanban).
gaborhojtsy As per @mixologic the DA has resources to do this, so it may eventually get blocked on core devs lacking yeah :smile:
gaborhojtsy @xjm The sprint tag is a good idea, I’ll see what I can do :slightly_smiling_face:
mixologic It would also be helpful to separate out the 'd9 readiness milestones'
xjm As in, vs. implementation issues?
mixologic Because some of them are things we want to do before we branch, some before we cut an alpha, and some before we release. etc.
xjm Ahh I get it
xjm So tagging separately based on which of those buckets it's in
xjm (Or something)
gaborhojtsy @mixologic separate them as in tags or issue structure? https://www.drupal.org/project/drupal/issues/3007300 has two children based on pre-branch / post-branch
mixologic i.e. a lot of the d.o. requirements probably need to be in place before we branch, and thus has a shorter timeline.
gaborhojtsy unfortunately many post-branch issues have pre-branch exploration/prepare components
xjm Maybe issue management/tags should be spun up into its own thread? Although we're almost at time
xjm So, maybe for next meeting :slightly_smiling_face: which we might want to reschedule given Christmas Eve is a holiday that will affect a lot of folks
mixologic sure. And there might even be things we can live with for a while that dont necessarily *block* branching, but should happen soon afterwards.
gaborhojtsy Done https://drupal.slack.com/archives/CDDD98AMN/p1544471861034300

5️ Open floor, what is on people’s mind, any unanswered questions?

6️ Issue organization. We have https://www.drupal.org/project/drupal/issues/3007300 as the master issue broken down to pre-branching and post-branching meta issues. All use the Drupal 9 tag though. Should we improve tracking of them?

xjm From @mixologic :
xjm > Because some of them are things we want to do before we branch, some before we cut an alpha, and some before we release. etc.
xjm > i.e. a lot of the d.o. requirements probably need to be in place before we branch, and thus has a shorter timeline.
xjm > sure. And there might even be things we can live with for a while that dont necessarily *block* branching, but should happen soon afterwards.
xjm So the meta already has one split; do we also want to adjust our tagging practices for this? And/or get more specific on the groupings on the meta?
gaborhojtsy the hard part for me was that post-branching issues mostly have pre-branch todos as well, eg. post-branching is actually make Symfony 4/5 required, but to support them optionally in 9 is pre-branch
gaborhojtsy “Must-have to branch Drupal 9” would be a suitable tag?
gaborhojtsy it needs to be quite specific :smile:
gaborhojtsy then “Must-have on Drupal 9 branch” maybe for the second group
xjm "Blocks branching 9.0.x"?
xjm Must-have-ness should be marked by the critical issue priority
xjm "9.0.x branching blocker" and "9.0.0-alpha1 blocker" and "9.0.0 blocker" or such
gaborhojtsy those tags would be more in line with our usual practice yeah — that said if its a blocker, it will be critical :smile: should haves will not block
gaborhojtsy I will look into separating the issues along those lines
gaborhojtsy I think 9.0.0 blocker is a bit vague, we know it means the release but adding the “release” word would be less ambiguous
xjm Right. I don't think we'd have many things in that box yet. Maybe some of the d.o stuff.
gaborhojtsy I was more thinking of drive-by tagging, that looks like an enticing one to tag all the things with
gaborhojtsy as something that blocks the brancing will *also* block 9.0.0 eventually :smile:
gaborhojtsy making it more specific about the release would be clearer
xjm Also stuff that can't be done _until_ 9.0.x is branched can be blocked on a single "Branch 9.0.x" critical issue that the RMs would own
xjm As in, marked postponed
xjm and the "Branch 9.0.x" would be postponed on its respective meta :slightly_smiling_face:
gaborhojtsy yup
gaborhojtsy will look into opening more of these so there are reference points
gaborhojtsy https://imgflip.com/i/2on25b

Comments

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

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#3019332: Use final to define classes that are NOT extension points

#3019332-14: Use final to define classes that are NOT extension points referred to this issue and then marked it postponed on D9, indicating it could only happen in D10. But this issue is empty. So I reactivated it until we have strong arguments to justify postponing it.

justafish credited Mixologic.

justafish credited NickWilde.

justafish credited alexpott.

justafish credited catch.

justafish credited mikelutz.

justafish credited starshaped.

justafish credited xjm.

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Issue summary: View changes
justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Issue summary: View changes
justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
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.