Meeting will happen in #d9readiness on drupal.slack.com.
| mixologic |
Deprecated scaffold files |
| xjm |
8.8.0-alpha1 commit freeze is nearly upon us! Update on D9 readiness issues that we need in 8.8. (jQuery, polyfills, Doctrine, others?) (edited) |
| mglaman |
Any news on Twig inspection? I haven’t poked, but I can pick up my work on phpstan-twig for inspecting compiled twig (hopefully makes it easier to parse Twig DSL) |
| wimleers (he/him) |
I don’t :neutral_face: I haven’t even gotten to the deprecated asset library deprecation stuff after you walked me through all that :disappointed: Still feel bad about that. But soooo much else came up. |
| valthebald |
Possible novice topics that can be worked on in Amsterdam? |
| xjm |
Yeah we had a whole bunch of stuff we suddenly discovered was on-:fire:-at-risk and @wimleers (he/him) was the :male-firefighter: ! Maybe next week we can discuss more? |
| xjm |
@mglaman @wimleers (he/him) I think we have a different thread for that though |
| shaal |
Any chance to get this in before 8.8 alpha?https://www.drupal.org/node/3086307 |
| xjm |
@shaal Well, it's not RTBC. But critical performance issues are something we'd also backport. |
| xjm |
(up until beta1) |
| mglaman |
ah I should try and write a patch for that |
| mglaman |
I think berdir suggested I try to write a patch which uses state to track rebuilds |
| mglaman |
during a testing profile install.. I think |
| xjm |
The issue is marked as a normal feature request -- is that accurate? Can we evaluate it against the criteria of https://www.drupal.org/core/issue-priority#critical-task and see if it;s a critical or major or what? :slightly_smiling_face: |
| xjm |
Performance is at least a task, not a feature |
| xjm |
This issue sounds risky though |
| mglaman |
@shaal do you have time to triage based on the above? ^ |
| xjm |
Risk of cache poisoning? |
| mglaman |
not that I’m super aware of. I tried reviewing. Route rebuild still triggers 4 times. during profile install. I just don’t know when |
| xjm |
If the risk is high as well as the disruption we might decide not to backport it. TBD though I guess based on a closer review. |
| mglaman |
for instance i’m pretty sure standard + umami mark the router to rebuild as part of hook_install |
| mglaman |
but it’s not a standard operation technically |
| Gábor Hojtsy (he/him) |
any other Drupal 9 topics? :wink: |
| Krzysztof Domański |
When contrib should specify core_version_requirement key? Drupal 9 has not yet started but many modules already have this parameter set (+core_version_requirement: ^8 || ^9). E.g. Advanced CSS/JS Aggregation, IMCE. I think it's too early. |
| wimleers (he/him) |
@Krzysztof Domański This is documented in detail in https://www.drupal.org/node/3070687 |
| Gábor Hojtsy (he/him) |
Thanks @mixologic for making DrupalCI support this new branch :slightly_smiling_face: |
| Gábor Hojtsy (he/him) |
we now have a daily test run that fails badly :smile: |
| xjm |
Yah that was like step 0.5 :smile: |
| mikelutz |
Definitely need to get those passing first. Wim is on it. :slightly_smiling_face: |
| Gábor Hojtsy (he/him) |
#3072702: Core extensions should not need to specify the new core_version_requirement in *.info.yml files so that 9.0.x can be installed is open to do that |
| Gábor Hojtsy (he/him) |
then we can update the PHP requirements and key dependencies |
| Gábor Hojtsy (he/him) |
see the complete list at #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 |
| Gábor Hojtsy (he/him) |
if all stars align then we can make alpha1 happen right before DrupalCon Amsterdam :slightly_smiling_face: |
| xjm |
also #3070401: Install profiles do not support multiple core branch compatibility |
| mikelutz |
I’m pretty well ready with a patch to update to SF4, including the new vendor deprecation suppression we will need. I’ll reroll it once the branch is passing. |
| mikelutz |
Not sure if we want to roll that into other vendor updates too. |
| Gábor Hojtsy (he/him) |
@mixologic for PHP dependencies, we are looking at Symfony 4.4 and Twig 2 for the first alpha |
| mixologic |
The tarball workflow will have to be in place for 9.0.0-alpha to be shippable, or, we'll have to not deprecate the duplicated scaffold files. |
| mixologic |
(until it is) |
| berdir |
there are also a bunch of other test fails still that the issues above won't fix |
| berdir |
seems to be related to d.o translation files as well as update.module data, I think we don't have issues for that yet |
| mikelutz |
I imagine it will take 3-4 issues/commits to get the branch passing. |
| mikelutz |
Might need a meta to track them. |
| wimleers (he/him) |
Yeah I’m working on those right now :slightly_smiling_face: |
| mikelutz |
Opened #3087874: [meta] Make 9.0.x branch pass testbot |
| xjm |
I updated #2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 to reference that instead of its children |
| Gábor Hojtsy (he/him) |
so https://localize.drupal.org/translate/projects/drupal/releases does not have 9.0.x because 9.0.x does not have a tarball yet |
| Gábor Hojtsy (he/him) |
is the translation fail related to that @berdir? |
| xjm |
Huh? 9.0.x has a tarball |
| xjm |
@Gábor Hojtsy (he/him) https://www.drupal.org/project/drupal/releases/9.0.x-dev |
| xjm |
Is there some reason l.d.o isn't picking it up? |
| xjm |
The branch doesn't even show up int he issue queue unless there is a tarball |
| berdir |
@Gábor Hojtsy (he/him) I didn't check, just saw that alexpott pinged you about that today |
| Gábor Hojtsy (he/him) |
@xjm yeah sorry l.d.o would need a tag’s tarball, it does not track dev versions, so people don’t need to follow a moving target |
| catch |
Do we need to skip that test to get things green, tag, then unskip? |
| xjm |
@Gábor Hojtsy (he/him) ohhh. So that's a chicken-and-egg problem...? |
| xjm |
Yeah maybe what @catch said |
| Gábor Hojtsy (he/him) |
why do we test something so dependent on localize.d.o? |
| catch |
I think there's an issue for it. |
| xjm |
Critical followup on the roadmap to unskip after alpha1? |
| xjm |
At least it doesn't test the internet anymore |
| mixologic |
if it has to hit l.d.o. it is |
| catch |
There's also #3016471: Make localization file download major version agnostic |
| mikelutz |
I opened #3087877: Remove test dependencies on localize.drupal.org |
| catch |
Thanks, if there is an existing issue for that, I can't find it. |
| xjm |
That last might be a dupe but we do also need to make sure we're not breaking it... we should dig out the discussions on old issues before ripping things out |
| xjm |
ah :slightly_smiling_face: |
| xjm |
But yeah, skip the test to unblock 9.0.0-aloha1 works for me |
| xjm |
Typo, but I'm keeping it |
| berdir |
I vote we rename alpha to aloha from now on. so much cooler |
| catch |
#3087877: Remove test dependencies on localize.drupal.org#comment-13309730 |
| mikelutz |
Of course, now that I’ve opened that, I can’t find an obvious test fail related to the translation files. |
| xjm |
I may actually be on the lower elevations of Mauna Loa when we tag one or two of the alohas. :volcano: :rainbow: |
| berdir |
see, perfect. it's decided then? |
| xjm |
Just need to get drumm to change the regex on d.o probably |
| xjm |
Clearly a top priority |
| berdir |
@mikelutz yeah, just going on what I read from slack. agreed, looking at the test fails now, most seem to be test modules and themes that can't be installed on 9.x, probably some hidden or even dynamically generated files or so? |
| xjm |
yeah we have some <<< crud or other dynamically written files in core tests I think (edited) |
| mikelutz |
I think we probably need to get something committed from #3072702: Core extensions should not need to specify the new core_version_requirement in *.info.yml files so that 9.0.x can be installed (whether it’s exactly right or not) so that we have a manageable number of test fails we can create issues against. |
| xjm |
@mikelutz when it goes from "build successful" to actual fails that's definitely committable |
| wimleers (he/him) |
Just posted a new patch: #3072702: Core extensions should not need to specify the new core_version_requirement in *.info.yml files so that 9.0.x can be installed#comment-13309774 |
| wimleers (he/him) |
Now I’m going AFK for dinner. By the time DrupalCI finishes, it’ll be a while past 10 PM here. Hopefully somebody in the US can continue :slightly_smiling_face: |
| mikelutz |
I’ll keep an eye on it. I don’t think I can RTBC though. |
| wimleers (he/him) |
I think it’ll need at least one round of actual review anyway! |
| mikelutz |
probably. We are just getting to the point where we need something to iterate off of. I don’t expect the big patch to fix every test failure. |
| wimleers (he/him) |
Indeed. There’s a few things out-of-scope here, a few things that require a D9-only patch for “other” failures |
| wimleers (he/him) |
The goal is to make tests run at all |
| wimleers (he/him) |
and to have the majority pass. |
| mikelutz |
Is your patch one you are expecting to commit to 8.9 too? |
| mikelutz |
so it should pass 8.9 tests? |
| wimleers (he/him) |
Yes. It’s also unnecessary for 8.9, but the goals for 8.9 and 9.0 is to be identical except for dropping BC layers. Therefore this should be committed to both 8.9 and 9.0.(I wrote that in #65, in response to you.) |
| wimleers (he/him) |
It’s right in the patch filename also :stuck_out_tongue: (edited) |
| mikelutz |
I hadn’t looked yet. |
| mikelutz |
I think that might be a good benchmark though, if it passes 8.9 and moves 9.0 from ‘build successful’ to a finite number of failures, I would say that’s likely committable. |
| wimleers (he/him) |
That’s my understanding, based on #3072702: Core extensions should not need to specify the new core_version_requirement in *.info.yml files so that 9.0.x can be installed#comment-13309290: Okay this patch should pass on 8.9.x and only have a few fails on 9.0.x which will be installable and testable - with unrelated fails. We still need another issue to actually fix the outstanding 9.0.x fails but I think they will require 9.0.x only fixes.(edited) |
| wimleers (he/him) |
For example, I am pretty sure there’s several failures due to translation downloads failing. That is certainly out of scope to fix here. (edited) |
| wimleers (he/him) |
Alright, dinner time! :wave: |
| mikelutz |
Go eat dinner, I’ll kick it forward this evening. |
| mixologic |
Translation downloads are reliant on #3016471: Make localization file download major version agnostic being fixed |
| Gábor Hojtsy (he/him) |
the translation fail could still be self-contained in core if it still assumes core compatibility in some way and hardcodes 8.x for example |
| wimleers (he/him) |
@mikelutz just fixed the 8.8+8.9 patch |
| mikelutz |
… you said you were eating and going to bed :stuck_out_tongue: |
| wimleers (he/him) |
I ate |
| wimleers (he/him) |
I checked back and found I created a mess. Would’ve been painful for you to figure that out |
| wimleers (he/him) |
All in your hands now :slightly_smiling_face: |
| wimleers (he/him) |
the DRUPAL_ROOT thing I mentioned you can already reproduce locally while tests are running, the 8.x patch certainly will fail on that |
| wimleers (he/him) |
but if all is well that would now be the only thing it’ll fail on |
| wimleers (he/him) |
also there’s docs nitpicks left, but I didn’t want to spend time on that prior to getting it to green |
| mikelutz |
I’ll try to get some green patches up tonight, you guys can hack them, RTBC them and commit them while I’m sleeping. :slightly_smiling_face: |
| wimleers (he/him) |
@mikelutz fyi https://drupal.slack.com/archives/CDDD98AMN/p1571085997157500?thread_ts=... |
| wimleers (he/him) |
coordinate with @alexpott! |
| Gábor Hojtsy (he/him) |
@mixologic raised this :slightly_smiling_face: |
| mixologic |
Hi. So we currently have two sets of scaffold files in core right now as per: https://www.drupal.org/node/3075873 |
| mixologic |
The original ones on the filesystem are deprecated for 9, and should be removed before alpha |
| mixologic |
(#3067645: Add core scaffold assets to drupal/core's composer.json extra field) |
| mixologic |
however, as soon as we do that, we do not have functional tarballs. |
| mixologic |
So, the packaging pipeline must be in place before that happens. |
| Gábor Hojtsy (he/him) |
@mixologic hm, how can we help with that? (edited) |
| Gábor Hojtsy (he/him) |
that sounds like a potential throwback :confused: |
| mixologic |
Well, packaging pipeline is somewhat of a DA internal thing, but, its all that we're working on besides the deprecation results. |
| mixologic |
I spent the weekend up to my neck in the PIFT codebase, so Im very familiar with it at this point |
| mixologic |
Which means, I'm going to have a much easier time implementing the finish line for the deprecation results on d.o. |
| mixologic |
so Im trying to get that knocked out. |
| mixologic |
Then the rest of the pipeline changes are the last focus |
| mixologic |
But, my point is that maybe even if we dont get those changes in place, we shouldnt have a 9.0.0-alpha until they are, because once they are, things might be different. |
| mixologic |
then again, I suppose there isnt a guarantee of alpha-alpha upgrades |
| Gábor Hojtsy (he/him) |
no alpha-alpha upgrade, definitely none |
| Gábor Hojtsy (he/him) |
I guess we could tag alpha1 but not add the release node for development |
| Gábor Hojtsy (he/him) |
I am not sure we even want a tarball of alpha1 @xjm? |
| xjm |
:thinking_face: The tarball is maybe the whole point? Are you thinking just tag without a tarball so that people who install core from git are the only testers? |
| xjm |
I mean we should be verifying that core gets composed and packaged correctly too with the new dependencies. For the 50% of sites that don't use composer to test. |
| xjm |
And yes, no upgrade path or BC promises between alphas; that will be explicit. and maybe blink-tag-bold-rainbow-marquee. |
| xjm |
I think I have sufficient privs on d.o to make that happen. |
| xjm |
@catch ^ thoughts about "tarball or no tarball" for alpha1? (not the blink tag rainbow marquee). For me the tarball's half the point. |
| mixologic |
I think if we dont get the packging pipeline in place it will be okay, because we're not offering alpha-alpha upgrades |
| mixologic |
We did everything imaginable to ensure that the composer generated tarballs had parity with the git clones |
| mixologic |
so, we should be good there. |
| mixologic |
but 9.0.0-alpha1 will have 'deprecated thingies' in it, without the pipeline. |
| mixologic |
But that should be okay, because its really just filesystem locations of duplicated files. |
| Gábor Hojtsy (he/him) |
@mixologic so why is it so important to remove those scaffold files, we’ll not remove most of the deprecated APIs either by alpha1 |
| Gábor Hojtsy (he/him) |
@mixologic if removing the scaffold files makes the tarball unworkable without significant work |
| Gábor Hojtsy (he/him) |
we can just delay removing the scaffold files until a later alpha :smile: |
| xjm |
What issue is this about scaffold files? |
| mixologic |
@xjm #3075873: Drupal "scaffold" files now duplicated in drupal/core is the CR |
| mixologic |
@Gábor Hojtsy (he/him) its not, and if thats okay and that there will still be api stuff todo, then we're all golden. |
| mixologic |
I thought the alpha blocker was "remove all deprecated code" |
| mixologic |
In any case, Im only raising this as "please dont remove these until the packaging infra is ready" |
| xjm |
Nooooooo nononon |
| xjm |
"Remove all deprecated code" is beta1 :slightly_smiling_face: #3079680: [META] Requirements for tagging Drupal 9.0.0-beta1 we're talking probably 3 months or more between alpha1 and beta1 |
| xjm |
@mixologic So I'd say explicitly postpone the issue on the infra blockers |
| xjm |
(You may have already; it just got lost in 80K tabs on my screen) |
| xjm |
@mixologic alpha1 is only about an installable tarball with significant dependency changes |
| mixologic |
perfect. yeah, I dont even know if there is a d9 issue for removing them |
| mixologic |
++ okay, great. |
| xjm |
#2608062: [META] Requirements for tagging Drupal 9.0.0-alpha1 those issues only :slightly_smiling_face: |
| mixologic |
pipeline will definitely be working by beta |
| Gábor Hojtsy (he/him) |
https://drupal.slack.com/archives/CDDD98AMN/p1571079194126500?thread_ts=... |
| Gábor Hojtsy (he/him) |
from @Krzysztof Domański |
| Gábor Hojtsy (he/him) |
I think its not honest to say the module works with Drupal 9 without there being a Drupal 9 branch to test it against :slightly_smiling_face: |
| Gábor Hojtsy (he/him) |
I admire the aspirations though and hope they keep it working though :smile: |
| mikelutz |
The problem with that statement, is that you need to specify ^9 to run the tests against D9 once there is one to run tests against… |
| wimleers (he/him) |
This is documented in detail in https://www.drupal.org/node/3070687 |
| mikelutz |
Do you want the chicken or the egg? |
| wimleers (he/him) |
If detail is missing, then let’s add to that |
| Gábor Hojtsy (he/him) |
@mikelutz well, you don’t need to commit that info file change to run the test |
| Gábor Hojtsy (he/him) |
it can be sitting on an issue |
| mikelutz |
fair.. I dunno, I know my modules are compatible, and if they aren’t we did something wrong in Drupal 9, lol. |
| wimleers (he/him) |
Right, in principle if your module has zero deprecation errors when tested with Drupal 8.8, then it’s ready for both Drupal 8.9 and 9.0 too. |
| wimleers (he/him) |
But between 8.8.0-alpha1 and 8.8.0, more deprecations could still be added. |
| wimleers (he/him) |
It’ll be a tiny number though! |
| wimleers (he/him) |
Wim waits for @xjm to prove me wrong :stuck_out_tongue: :fire: |
| Gábor Hojtsy (he/him) |
@wimleers (he/him) your module could still use old things in dependencies, that are not discovered with 8.8 AT ALL |
| wimleers (he/him) |
oh you mean Drupal’s own dependencies? |
| wimleers (he/him) |
so if those dependencies themselves are not trigger deprecation errors appropriately? |
| Gábor Hojtsy (he/him) |
well, Drupal 8.8 will not trigger Symfony 4.4 deprecated API errors, because it does not contain Symfony 4.4 |
| wimleers (he/him) |
right |
| Gábor Hojtsy (he/him) |
so your module may rely on something from Symfony that got removed, testing against Drupal 8.8 will never discover that |
| wimleers (he/him) |
we so very badly need matrix testing /cc @alexpott @lauriii |
| mikelutz |
Well, when I say I know my modules are compatible, I mean I know… Me, being quite familiar with all the deprecations, SF4 stuff, other vendor changes, etc… :stuck_out_tongue: |
| Gábor Hojtsy (he/him) |
well, we want to achieve alpha1 for DrupalCon with SF 4.4 and Twig 2 for this :smile: |
| wimleers (he/him) |
So literally one person in all of Drupal land can say that :upside_down_face: |
| Gábor Hojtsy (he/him) |
it will still leave some smaller dependencies that but they should have less of an impact surface |
| wimleers (he/him) |
indeed |
| mikelutz |
Does that make me the world’s foremost expert on Drupal 9? :stuck_out_tongue: |
| wimleers (he/him) |
PUT THAT ON YOUR LINKEDIN PROFILE |
| wimleers (he/him) |
recruiter spam through the roof |
| xjm |
@wimleers (he/him) A tiny number, but HUGE deprecations potentially. Whole libraries. Up until 8.0.0-beta1. (edited) |
| mikelutz |
lol. :slightly_smiling_face: |
| wimleers (he/him) |
See, that’s why I added the @xjm-caveat |
| xjm |
Specifically the three polyfills and 20 bazillion jQuery UI libraries we're deprecating may end up being after alpha1 |
| xjm |
(Depending on reviews etc. in the next, oh, 24h) :stuck_out_tongue: |
| wimleers (he/him) |
What you just referred to is solely JS though. And yes, those we know will still happen. |
| wimleers (he/him) |
(Most Drupal contrib modules do not contain JS, hence the “solely”: most won’t be affected.) (edited) |
| xjm |
@wimleers (he/him) well, also maybe the entire block_place module for example |
| xjm |
And um. SimpleTest stuff maybe also. |
| xjm |
Things will be evaluated case-by-case, but things that affect the security, stability, and technical debt of D9 are going to get careful impact vs. disruption consideration if we look at committing them between alpha and beta. |
| mixologic |
Thats why it has "simple" in its name. Because it will be simple. |
| mikelutz |
Big difference between ‘SimpleTest removal’ and ‘Simple test removal’….. |
Comments
Comment #2
gábor hojtsyComment #16
gábor hojtsySaving meeting log and credits. Thanks Slack for expanding non-profit's free accounts to standard.
Comment #17
gábor hojtsyFix markup.