Moderated By: gaborhojtsy

[0] Let’s introduce who we have here and what are you all here for

gaborhojtsy Gábor trying to get his stuff together :smile: looking forward to map out the tasks and timelines
xjm Hi! xjm, D8 release manager. So basically I have to care about everything we need to do with D8 and D9 core to get to that 2020 release date for 9.0.0. :slightly_smiling_face:
mixologic @mixologic here from the DA. Im primarily concerned with how D9 is going to affect the services that the DA provides, including localize, updates, drupalci, project pages, and drupal.org in general
phenaproxima Adam of Acquia. I’m concerned with things like Composer-readiness, refactoring the migration system, and getting the media module to a state where it can replace File and Image
mglaman Matt, hanging out to watch. Also to fix contribkanban board for this :stuck_out_tongue:
mikelutz @mikelutz Michael Lutz here. Been working mostly on the migration systems lately, but generally trying to keep informed of everything that’s happening with the transition to Drupal 9. Mostly here to listen and learn.
tatarbj :wave: Balazs from Belgium is present. I've been promoted recently at my work (European Commission) to an IT Security Analyst and also being 'Drupal Security Correspondent' to take care of our drupal services from vulnerability management perspective. My reason to be here is to be more involved in the community and help to bring core forward :slightly_smiling_face:
hestenet (he/his/him) Tim (interim executive director at the DA) from Portland, OR - just here to lurk :slightly_smiling_face:
drumm Neil Drumm, also from the DA & lurking :slightly_smiling_face:
mirom Miro from Slovakia; just hanging around, happy to help with stuff re easy transition from d8->d9
Nick Wilde Nick Wilde, Victoria BC, mostly lurking, occasionally skulking, very rarely biting off fingers in Mt Doom.

[1] I started tagging issues with “Drupal 9” and have a core board for now at https://contribkanban.com/board/d9readiness — any issues you are aware of that should be tagged

mglaman note: if you find problems using the board, ping me
mixologic Does that only cover drupal core, or does it get stuff cross project?
mglaman https://contribkanban.com/sprint/Drupal9 this is cross D.o
mglaman _but_ the “sprint” view doesn’t show postponed
gaborhojtsy @mixologic for now that is Drupal core but apparently we are also tracking the multi-core-compatibility stuff there for some reason
mglaman @gaborhojtsy bah it’s not limited on that board?
gaborhojtsy on fixed issue we have for now is the public dates posted at https://www.drupal.org/node/2383987/revisions/view/11133105/11151440 :slightly_smiling_face:
xjm Other issues to locate and tag: Twig 2, Symfony 4. Meta question about Symfony 5. The dependency update issue as we need to resolve those other things.
mixologic As we identify changes that need to be made to drupal.org, just making sure that they also show up if they get tagged (i.e. project module, etc)
gaborhojtsy @mixologic just use the “Drupal 9” tag
mglaman So

- Generic issue tag board: https://contribkanban.com/sprint/Drupal9
- Core specific https://contribkanban.com/board/d9readiness
xjm Issue to file/postpone: bumping PHP and DB version requirements
xjm Another issue that may exist already is the policy issue about Migrate vs. update path for D8 to D9; and about D6 sources in D9 or no.
xjm And the metas about deprecations
gaborhojtsy I will try to make note of those and tag more but please help :slightly_smiling_face:
xjm (Just braindumping)
mikelutz I just tagged https://www.drupal.org/project/drupal/issues/2607524 which covers both of those.
tatarbj I would also propose to start semantic versioning for contribs when 9.0.0 will be released - could be a good way to have better coverage for contribs (i've seen an issue on d.o regarding this, could be tagged with 'Drupal 9')
xjm Yep, the core blockers for contrib semver that I know of appear to be already on the board.
xjm Although I would say we want that before 9.0.0
xjm An important thing to keep in mind is that 9.0.0 includes _no new features_ over 8.LAST which is released simultaneously. We should align with that for d.o as well.
tatarbj tbh i wouldn't bother the d8 ecosystem with it, rather introducing the concept and make it hardened from 9.0.0
xjm We want 9.0.0 to be as non-disruptive as possible for contrib
mglaman Yeah. We haven’t had official discussions but I would consider Commerce 3.x to be for D9
xjm Thus we need to roll it out beforehand
drumm The d8 ecosystem is already somewhat bothered with it, Composer support does some faking of semver.
xjm So those are blockers to opening 9.x at all from a release manaement perspective :slightly_smiling_face:
tatarbj we should also create (if it doesn't exist already) a meta issue for security coverage when 9.0.0 will be released. ideally it will not break BC but a transition period could be needed to cover 8.LAST as currently 8.current-1 is covered.
xjm The policy for this is already set :slightly_smiling_face:
xjm So no need

[2️] Changes to drupal.org services for d9 support

mixologic So I dont see any prerequisites on https://www.drupal.org/project/drupal/issues/2608062 that involve drupal.org, but I think there might be some.
mixologic I think the biggest change for us is going to support, conceptually, that a contrib module can be both d8 and d9 compatible.
mixologic Both localize.drupal.org and updates.drupal.org have the 'major version compatiblity' as part of the URL.
mixologic Much of the content model of finding extensions also has "Core compatibility" as an option.
gaborhojtsy @mixologic I think there was one issue for that that I may have tagged
mixologic @gaborhojtsy is this the one? https://www.drupal.org/project/drupal/issues/2807145
gaborhojtsy @mixologic yes
xjm I would say that and contrib semver support are the two d.o things with the earliest "due dates" if you will. And both I think are blocked on core presently.
gaborhojtsy @mixologic it may be that there is already a d.o infra issue as well but I am not sure :slightly_smiling_face:

[3️] Our main plan issue is https://www.drupal.org/project/drupal/issues/2608062, we should identify any missing items like @mixologic in 2️

mixologic From a D.O. perspective, we'll need to figure out what needs to be in place to support *opening* the d9 branch, vs. what needs to be in place before we can *release* d9.
xjm The latter is probably actually technically "before we can release 9.0.0-alpha1"
mixologic i.e. we probably don't need to solve updates and localize urls as a prerequisite, but perhaps module compatibility needs to be addressed.
drumm I think 9.x is already technically branched, so issues can be filed against it. It’ll need a big ff merge next.
gaborhojtsy yeah it will need to be “rebranched” in some way :slightly_smiling_face:
drumm And might be not exactly the right branch if it was made pre-semver
xjm Yes, we will want to kill 9.x in favor of 9.0.x
xjm Since the code in 9.x is either about 5 years old or the branch is empty; I forget whether we actually did the last or just discussed it :slightly_smiling_face:
gaborhojtsy sounds like a nice solution :slightly_smiling_face:
xjm I would definitely branch 9.0.x fresh from HEAD rather than doing any merge
xjm Once that's done we can bulk update core issues like we do for minors
berdir @gaborhojtsy I would say getting rid of all deprecated usages should be a requirement, maybe not to start the branch, but to finish it, and for that, we need both our usages removed and all BC layers and @trigger_errors() out/replaced with hard errors
xjm Removing usages is a requirement to open
xjm Per RM consensus anyway :slightly_smiling_face:
xjm So that it's fast(er, ish) to remove the BC layers once the branch is open

[4️] State of migrate. Do we have the respective issues for migration stability and 8-8 migrations that are listed in https://www.drupal.org/project/drupal/issues/2608062?

gaborhojtsy I believe we have https://www.drupal.org/project/drupal/issues/2208401 for migrate multilingual that is the only missing experimental piece
gaborhojtsy These two items pertain to migrations from the policy issue: “1. The core migration path from 6.x and 7.x to 8.x must be stable before 9.x is opened. We must decide whether to support direct migrations from 6.x to 9.x (catch thinks we should).

2. Either core migrations from 8.x to 8.x or the ability to upgrade 9.x in the same way as an 8.x minor release (using update.php) must must be stable and documented. Both could be available. If there are two parallel systems in place (for example and old and new path aliasing] system, then a migration from one to the other must be available.

”
mixologic Really curious about why we might support a d6->d9 migration path.
mikelutz @heddn
gaborhojtsy we already have in d8
mixologic unless its really not that different from d6->d8 since they'd be essentially the same
xjm @mixologic Because 5-10% of sites are still on D6 and it's trivial to create. The non-trivial part is potentially maintenance until 9.LAST.
xjm We'd move it into a contrib project even if it weren't in core
xjm Open question though
xjm Well the other non-trivial part is upgrade path testing. I think upgrade path tests are the last great bastion of Simpletest.
xjm Obviously the sooner Migrate Drupal Multilingual is stable, the better for the ecosystem as a whole and for the D9 timeline :slightly_smiling_face:
heddn Anything we can do to reduce the amount of code we need to support, the better. Ergo why I raised the question about sunsetting support for a direct 6=>9 upgrade path.

[5️] Timelines for experimental modules. Do we have plans for them to get stable no later than 8.9?

xjm Relatedly, @catch and I are aligned on no new experimental modules being added in 8.LAST-1.
webchick I’m not sure we have plans to add any more, from a product POV. Only pending one I can think of is the Topic-based Help system.
webchick *eyeballs* https://docs.google.com/document/d/1mpdlg4mo2Pv3W-armOtJkhvkdkZJb4_SiSrh...
gaborhojtsy :yay:
webchick Ah, I guess admin UI stuff.
webchick And JSON API
xjm Arson and Jaywalking there, lol
webchick And automated updates
webchick And config transofmer
webchick so yes nevermind me. :smile:
webchick However, the rest of the initiatives are firmly on “stabilize what’s there” (Layout, Media, OOTB, Migrate, Workflow…)
gaborhojtsy haha :smile:
xjm @webchick I guess a related question would be, given that we are on a clock for 9.0.0, which of those things are priorities for ASAP, vs. potentially targetable for 9.1?
webchick Hm. I guess I think stabilizing the existing features already landed has priority over new things. But I also barely had coffee yet, so reserve the right to amend this opinion in the future. :smile:
webchick But anything that hasn’t made it in by, what? 8.7? 8.8? We should probably target for 9.1
webchick (as far as new things go)
xjm Agreed
webchick And I would like to give until 8.8, if we can, because that gives essentially an 18 month long feature freeze.
webchick Correct
webchick ?
xjm Well we open 9.1.x when 9.0.0-alpha1 is tagged
xjm so less hopefully
webchick Ah, right.
webchick So roughly a year, but 18 months for end users.
webchick Per the original question tho:

- Admin UI looks like it won’t make Drupal 8, unless they make a radical change in direction.
- Seven redesign ideally will, but lots of things up in the air atm.
- JSON API “should” land in 8.7, and as stable vs. experimental.
- Automatic Updates, nfi. If it doesn’t hit 8.8, probably it’s 9.1
- Config Transformer seems on track for 8.7, plan to stabilize by 8.8
- Topic-based help system, ideally makes it in 8.7, stabilized by 8.8
- Layout, hoping to stabilize by 8.7
- Media, hoping to stabilize by 8.7
- Migrate, hoping to stabilize by 8.8
- OOTB is “ever not stable” but aiming to run point with whatever features make it into each release
- Workspaces, looks dodgy to stabilize for 8.7, but hopefully by 8.8

[6️] Any last words, what did I forget, what do you suggest for the next meeting?

tatarbj i just love the format to open it here in slack and would love to continue it same way :slightly_smiling_face:
gaborhojtsy ok I should be more prepared next time with threads :smile:
gaborhojtsy now that we know who is attending
xjm I'd like to have an open thread about how we can start driving resource allocation to this all
tatarbj @gaborhojtsy for kicking it off i think it was perfect :slightly_smiling_face:

Comments

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

justafish credited Mixologic.

justafish credited drumm.

justafish credited hestenet.

justafish credited larowlan.

justafish credited mglaman.

justafish credited mikelutz.

justafish credited phenaproxima.

justafish credited tatarbj.

justafish credited xjm.

justafish’s picture

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

justafish credited Berdir.

justafish credited NickWilde.

justafish credited heddn.

justafish credited mirom.

justafish credited webchick.

justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
justafish’s picture

justafish
she/her
Primary language English
Location London, UK
commented
Status: Active » Fixed
justafish’s picture

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

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.