Meeting will happen in #d10readiness on drupal.slack.com.
| Spokje |
(I helped myself to a thread :slightly_smiling_face: ) |
| Björn Brala (bbrala) |
Hey there deprecation boss. How is it going then :slightly_smiling_face: |
| larowlan |
Let me know if you need reviews |
| andypost |
As I got we do deprecation ATM, so removals are delayed? |
| Björn Brala (bbrala) |
Removal is excerpt? |
| catch |
Yes module and theme removals are fine in 9.5.x |
| andypost |
I mean we do deprecation but when removals could start to land? For example color/aggregator are deprecated but not removed |
| Spokje |
Looks like we're running a bit out of steam on this one.Most issues are needing review or committing of blockers, not so much actual work on the deprecation/removal issues themselves. Most of them involve changing fixtures, which are certainly not very git-mergeable friendly. Meaning one deprecation/removal has to go in, with it changed fixture(s)), before the next one can have it's fixtures updated.So we need help with Review/Committing. Here are a few "highlights":Needs Review: #3243121: Remove RDF module from the Standard profile |
| Spokje |
AFAIK: Removal is still in full swing as well as deprecation.Color is indeed deprecated not removed (for reasons unknown to mankind). Aggregator is both deprecated and removed AFAIK. |
| catch |
Is color stuck because of bartik and seven maybe? |
| Spokje |
Not that I know, we agreed to keep the color.inc in all themes-to-be-deprecated. Wim Leers agreed with that.There are no blocking issues listed, nor can I find one if I scan the remarks/answers in the issue. |
| Spokje |
AFAICT: The removal not happening was/is just an oversight? |
| catch |
Hmm we should just try it :) |
| andypost |
There's https://www.drupal.org/project/drupal/issues/788332 which sounds helpful for Olivero but it's feature so waiting for approval |
| Spokje |
Hmm we should just try it :)I like your chutzpah, young man! :slightly_smiling_face: (edited) |
| Spokje |
IMHO: We've thrown the dice when we deprecated color. We have to remove it now as well. Without all the fancy follow-ups that might be done in time for 10.0.0 (edited) |
| andypost |
At least CI passing #3270899: Remove Color module from core |
| Spokje |
Just updated the MR (again) one hour ago :innocent: |
| Spokje |
All the mentioned issues above should have passing MR, I've been updating them in the last few days. Just need TLC for reviewing and/or committing, so we can move on with some more actual deprecating/removing |
| andypost |
Colors.yml issue probably should go to 10.1 but requires subsystem maintainer's POV |
| catch |
I'll try to look at the rtbc tracker blocker when I'm back on laptop. |
| Spokje |
Colors.yml issue probably should go to 10.1 but requires subsystem maintainer's POVIMHO we can't wait on that for removal. Color will live (long and prosper) in Contrib, and with the color.inc staying in themes-for-removal like Bartik and not being used in Claro and Olivero, I think the case for removal of Color from Core in 10.0.0 is a strong one.(Besides that: OCD-Spokje screams at a module being deprecated already and not removed... :scream: ) (edited) |
| andypost |
Yes, but this API could be helpful for Olivero and other 10.x themes |
| Spokje |
Not saying the API isn't helpful, just saying it isn't IMHO a must-have before Color can exit-Core-stage-right. |
| Spokje |
If it is: We should state it in the issue for the removal of Color: #3270899: Remove Color module from core because now it has no blockers listed. |
| andypost |
IMO the issue is rtbc but would be great if @wimleers (he/him) approve it |
| Spokje |
Fully agreed on that |
| xjm |
The main thing we need to do before removing them from 10.0.x is ensure that the composer façade naming for them is fixed, and have someone manually test EACH to confirm downloading the contrib module in D9 and installing it works SEAMLESSLY, and that it then does again if the rm -rf core/modules/foo |
| Spokje |
Hmmm, that's a new one for me, shouldn't that be in the documentation as well? https://www.drupal.org/about/core/policies/core-change-policies/module-o...…]-to-a-contributed-project (edited) |
| xjm |
@Spokje I was positive that it was and I bring it up every time. /cc @quietone |
| xjm |
There were two copies of docs at one point and I think the one with the more info lost to the one with the more modules and less info |
| Björn Brala (bbrala) |
I do feel it was part of the process yeah. Something about drupal/hal-hal :x |
| catch |
@xjm I think the DA is trying to do them in batches, not sure it should actually block because it only becomes an issue when the 9.x release gets to rc1 which isn't the same as removal. |
| catch |
Will find an issue... |
| xjm |
The core module needs to have a stable release and be upgradeable safely before it's removed from core |
| catch |
#3266395: Ensure that hal do not get special core treatment |
| xjm |
Otherwise, the module is not being moved smoothly with a one-line change |
| catch |
And #3266476: Ensure that quickedit does not get special core treatment |
| xjm |
At least, all the ones deprecated in 9.4.x should have their names fixed and be manually tested with D9 and with 10.0 |
| xjm |
And it should be blocking because otherwise we need to keep the modules in D10 if they don't have a working upgrade path with a one-line change. |
| catch |
Well the DA has been deliberately not doing them afaik so it's just not working like that atm. |
| xjm |
They need to stay into 10.0.x until it's done, period |
| catch |
We can't do it until they're deprecated in 9.x, and that needs to happen around the same time as removal. |
| catch |
i'm trying to find the issue where this was discussed recently. |
| xjm |
I think the remove at the same time is all very nice if the ugprade path is working |
| catch |
If we're going to block it on the DA, then we'd need the DA to make the change before things are deprecated, which is backwards IMO - the deprecation work is not straightforward. |
| xjm |
However, it should not happen utnil we've proved that the upgrade can be done safely. Otherwise we'll have to add the damn things back. |
| xjm |
I disagree; it can be done between deprecation in 9.x and removal from 10.0.x |
| xjm |
The upgrade path is more important than whatever the reasons people want those things to happen at the same time are |
| catch |
It was 5 months ago and in slack :confused: #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib#comment-14381856 |
| xjm |
@catch I'm not concerned that the DA doesn't do it immediately. But I AM concerned about rm -rf from core before we've made sure the actual upgrade path works, because if it doesn't, we're adding critical release blockers to D10 then. |
| catch |
We're talking six months, not immediately. |
| catch |
#3266476: Ensure that quickedit does not get special core treatment#comment-14578049 |
| xjm |
After 9.4 would be a good time to ask that it be fixed for all the mdoules that were deprecated in 9.4, and those should ahve their upgrade paths tested thoroughly. |
| catch |
#3266395: Ensure that hal do not get special core treatment#comment-14578051 |
| xjm |
Again, I will repeat: Let's get it handled for the modules that were deprecated in 9.4. |
| catch |
Yes I've bumped those two to critical. |
| xjm |
And not remove any further stuff from 10.0.x HEAD until this is sorted; there are only 2.5 months anyway; they can't get away with waiting for 6. (edited) |
| catch |
for me the removal issues are also release blocking if we've deprecated them already, because we'd have to un-deprecate. So we are still leaving unresolved release blocking issues against the core queue, just ones that are postponed on the DA. (edited) |
| xjm |
But it's easier to remove it cleanly once it's fixed than to have to re-add it back to core |
| xjm |
I will put this on the next DA/committer meeting agenda |
| xjm |
Since we are approaching beta, we should have deprecated modules have this addressed once per month, and then have the 10.0.x removal happen after the manual testing has been done and confirmed. |
| catch |
Part of the reason to commit the 9.5.x deprecation and 10.0.x removals close together is to avoid having to have 10.0.x deprecation, 9.5.x deprecation + 10.0.x removal patches, I think we need to stick to that to not add an extra 1-2 patches on top of the multiple sequential patches we already have. This means 9.5.x and 10.0.x diverging in a slightly odd way if they're further apart. |
| xjm |
I'm not worried about extra patches; I'm worrying about shipping a major release and telling people all they have to do is add one line to use any of 10 deprecated modules and themes and then it turns out none of it works and we have 10 criticals. |
| xjm |
So let's talk to the DA about it and get the timeline fixed. |
| xjm |
Even the removals of the stupid stubs caused regressions with D9 |
| catch |
We've already done that by shipping 9.4.0, I don't think the removals are the problem here. |
| catch |
It's not going to break your install in 9.4.0, but it's going to tell you to install the contrib module to quieten the status report warning, and that's the point where people will run into issues first. (edited) |
| xjm |
I will die on this hill |
| xjm |
We need to manually test these upgrade paths prior to beta1 |
| xjm |
And if they're broken, they block beta |
| xjm |
In the future it won't even be possible to do the removal issues at the same time as the deprecation -- modules should be deprecated in 10.1.x and 10.2.x, not 10.4.x and 10.5.x. The fact that we're allowing it now is only because we didn't have a choice. |
| Spokje |
Right....walking away from all deprecation/removal issues after reading the above. I do see the validity of having a valid and working upgrade path. Not so much feeling the love for changing the rules so late in the game.I'm not waiting around for the DA to fix something that has been floating around since 6 months already. O well, enough to do in the d.o, queue anyways :) (edited) |
| xjm |
We have a meeting with the DA next week and I will raise that it's critical to resolve |
| xjm |
Also I don't know who came up with the "rules" that you didn't need to ensure the module worked when you moved it to contrib; I certainly was not consulted and I bring it up literally every time we talk about it. |
| xjm |
And I don't understand what's so hard about committing the deprecation patch to 10.0.x; seems like the easiest thing in the world |
| xjm |
People keep saying that it should be removed around the same time but I have never seen any source for who decided it in the first place, and it certainly wasn't this third of the release managers consulted. |
| xjm |
We create 4-5 versions of every patch that touches CKEditor 5's JS because the builds are different, in hundreds of issues; we can make two for a list of module removals that is less than 10. I am just not getting it. (edited) |
| Spokje |
Not getting this all either. Again: I totally see your point about a smooth upgrade path, but it's just the straw that broke this camel.I've created about 30 issues to get (only) Quick Edit to very close to removal, we defined the process as we went along. I was very happy about the excellent documentation about that made by quietone (and larowlan), but adding a (for me) new step now, so late in the process, takes my motivation away.But that's just me, there are plenty of good people out there that can hop in and drag all/some modules to the finish line. :wink: |
| Spokje |
I'll just add some issues for updating the facade for modules I've worked on and postpone the issues on that one, so everybody is clear on where we stand. |
| xjm |
@Spokje Sorry that you are feeling burned out about it :disappointed: |
| Spokje |
No worries, this is just a whole new process which IMHO never works at the first stab.We came far, so somebody will get it over the line (or not, and then there's always 10.0.1 or even 11.0.0).The main thing I wanna get across that it's really annoying (at least for me) when the rules are changed whilst your playing the game.I can see that you indeed mentioned the manual test and facade change a lot of times, but somehow, that got "lost in translations", and not only for me, because it never made it into the official documentation.In all honesty: I can live with the manual testing, the one that really got me is that we have to have a working facade.With all respect for the DA and all the good work they do, this is very much a black box to me. For "normal" code issues I know who I can hunt down and annoy into reviewing/helping, for the DA not so much.Seeing that the existing facade changes issues are in slumber for quite a while, I personally do not have the patience to wait on those before actually "doing stuff".Also I find it weird that the (again very needed) manual testing now is a blocking issue, whilst we already deprecated/removed IIRC 3 modules months ago, where this has not been a blocker.Again: It's just me, plenty of good people around to carry on, but we might want to refine our documentation/processes a bit more before we let people jump into them, it might prevent other people to bang heads on keyboards and walk away :slightly_smiling_face: |
| catch |
Apparently the facade issues that were opened already got done, just wasn't documented on the issue.https://drupal.slack.com/archives/C014CT1CN1M/p1655767174214809?thread_t... for me this is exactly the problem with making the DA a bottleneck for specific core issues - we don't have control over what the DA tells people to work on at any one time and the issues aren't against core. It's not like we haven't been opening and tracking those issues either, but once they're open there's nothing we can do except harass people. |
| catch |
fwiw I did the manual testing. We do have an issue on 9.4.x/9.5.x, because of the facade change probably (drupal/quickedit-quickedit probably would have installed, but drupal/quickedit composer does not like). 10.x update is smooth apart from contrib quickedit falling behind with the multiple core blockers that have landed since the last time it was updated. |
| catch |
#3227033: Remove Quick Edit from core#comment-14578766 |
| Spokje |
Final remark from me in this thread and on deprecations/removals in general:Why do you want to install the Contrib incarnation of a module on 9.4.x/9.5.x where the module is still present in Core, but "only" deprecated? |
| catch |
@Spokje sorry to drag you back in. tbh I am not sure, I just tried it. Since core provides the package in 9.x then a contrib module with a new dependency ought to be fine - composer will know it's there from core, and they can just add it as part of the 10.x update work. However we always used to allow people to replace core modules with contrib modules (the directory parsing is ordered so that replacements in /modules and /sites/*/modules come last), and composer is essentially preventing that. |
| Spokje |
Ah, so it's this bit in core/composer.json that is the killjoy?"replace": {
"drupal/quickedit": "self.version"
}If so, we might have a problem, because removing it seems to imply basically removing the module from core.For this specific (odd) use-case the drupal/quickedit-quickedit namespace actually might have worked fine :partying_face:Then again: I have no clue whatsoever is done in the "composer facade" to make "stuff" happen.Which is basically also the reason I'm bailing, there's just seemingly no way to:Make DA communicateMake DA prioritizeHave a clue what's going on there.Again with all the great respect for the great work they're doing and their limited time, this is, like you yourself said, not a great link to add to the already fragile chain of deprecation/removal of Core modules.I personally really don't have the patience to wait for the black box that is DA to me to do something at some point and then hurry to get our bits updated/working/committed.But again: That's all just one persons opinion. I'm sure you and all the good people in the queue will eventually get (some) modules/themes out of Core. |
| catch |
I think we can probably just say 'composer require in 10.x, don't do it in 9.x' and then fix it forever in #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib |
| Spokje |
Make sense, unless "dramatic" changes are made in the Contrib incarnation that would make the Contrib module superior to the (still present) 9.4.x/9.5.x Core module. Then people would want the Contrib incarnation on 9.4.x/9.5.x as well.Which would imply fixing #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib before we move on with the whole deprecation/removal-dance. (or just don't improve the Contrib incarnations until we've dropped D9 altogether... :smiling_imp:) (edited) |
| Spokje |
Hmmm, if composer require "drupal/quickedit-quickedit" still works we might advice that for the D9.4.x./9.5.x users.Although that doesn't really make things more clear, it might prevent us fixing the above mentioned issue and keep moving forward. |
| catch |
That actually does still work apparently. |
| andypost |
Does it mean we should duplicate module name for facade? So color-color is ok? |
| Spokje |
Well, it is a workaround (I'm guessing requiring quickedit-quickedit actually works on 9.4.x/9.5.x). Not the most clean one, but hey, when are workarounds clean anyways... :smiling_imp:It would prevent us from going into the (probably) dragon-riddled woods of #3188544: [policy discussion] Address Composer namespacing issues when extensions move between core and contrib and grind to a halt with all deprecations. |
| catch |
this is why the facade works the way it does for core modules, but people were incredibly confused when we originally moved simpletest out, which was why we changed the facade to drupal/simpletest (eventually). |
| dww |
I completely feel @Spokje’s pain here. And I agree with @xjm that the “deprecate and commit within 24 hours” thing is weird and unexpected. I raised that in (one of) the QE meta(s). I don’t know when / where how that was “decided” or how that became part of the expectation.This is a hard, confusing process, and we’re having to figure it out as we go. |
| catch |
The idea with 'deprecate and remove within 24 hours' was from me so that we wouldn't have to do deprecate in 10.0.x, deprecate in 9.5.x, remove in 10.0.x and instead could do 'deprecate in 9.5.x, remove in 10.0.x', specifically because we are dealing with chains of issues 5-20 issues long for every module. (edited) |
| Spokje |
Does it mean we should duplicate module name for facade? So color-color is ok?What I'm trying to say, we could do (for your color example):composer require 'drupal/color:^1.0' for 10.0.xcomposer require 'drupal/color-color:^1.0' for 9.4.x/9.5.x |
| catch |
i think that's good enough for people who really want the contrib version in 9.x |
| dww |
Eg I did the QE subtree split ages ago, foolishly thinking we were close. But we actually need to do it very late in the process. I need to wait until core’s done changing stuff. But core can’t be done changing stuff until we have a bullet proof upgrade path. So we have like 4 things that effectively have to happen simultaneously, with at least 3 different key people (core committer(s), contrib maintainer(s), DA tech staff). That’d be hard enough to to coordinate even if everyone was an Acquia employee :sweat_smile:, but we’re usually talking 3 different orgs... |
| Spokje |
I actually think the "24hrs-solution" made/makes sense, saves us from committing the deprecation patch/MR on 10.0.x .What didn't/doesn't make sense is why we abandoned it on the Color module. |
| catch |
The removal patches aren't simply rm -rf, even with 20+ blocking issues, they're doing things like removing from database test fixtures which breaks every time a removal patch gets committed, or we remove core updates etc. |
| catch |
It wasn't a hard requirement to land them within 24 hours, it was just a suggestion that we get both patches ready in different issues, so that we can deal with the half-dozen spin-off blockers that each uncover, and make sure they're both ready to go before we pull the trigger on either. |
| Spokje |
The fixtures are indeed the real pain here, they are in no way Git-mergeable whatsoever. Meaning that you really can't set them up for multiple issues, but rather have to wait until one is committed, and then redo the whole process for the next issue on the changed fixture(s).Might be me, might be that I'm on Windows (Yes, I am the lonely one....), but changing a fixture roughly takes me around 30-45 minutes. |
| catch |
Because the removal patch is the best way to test that we've done everything we possibly can prior to the deprecation patch landing. |
| catch |
Even when we're on 10.1.x and doing this, I still think it'd be useful to have an RTBC removal patch alongside the deprecation one so we know we're done as much as possible. |
| Spokje |
Fully agreed on the removal patch being the "Hard Test", but even when it's not a hard req to land the removal patch within 24 hrs, not doing so for more than 1 month leaves the deprecation vulnerable, what if we discover new stuff in the removal, we have to repatch the deprecation. |
| catch |
I have thought about pre-emptively removing modules from database fixtures en-masse, but then we're dropping test coverage for an unspecified amount of time before those modules are removed, which is not usually a popular decision. Also don't know if that would cause its own complexities. |
| Spokje |
^Yeah, sad but through. It would muddle the waters even more IMHO. |
| catch |
Like the 9.4.0 fixture could just happen not to have 5-10 core modules in if we uninstalled them after running updates and before re-recreating it, but then we've got to also modify the test coverage. Some generic tests might be relying on them. |
| Spokje |
It just sounds messy to me. |
| catch |
Yeah I think it's just easier to deal with them sequentially, we don't have that many update/module removal issues for the actual removal. |
| Spokje |
Agreed, it just means we basically can do all the "fringe"-issues of a deprecation/removal simultaneously, but when it comes to the actual deprecation/removal issues themselves, there can be only one(TM) in the active process. |
| xjm |
These models have data associated with them |
| xjm |
They have configuration, even content data |
| xjm |
Just being able to require the module isn't enough; it also has to work. The last time someone actually tested one, it was completely broken. |
| Spokje |
Excellent, how do you propose we determine "It also has to work"? |
| xjm |
I dont' understand the question |
| xjm |
Install D9 with the core module configured and containing data. Download and install the contrib one. Update to D10. Ensure nothing breaks and all the data is where it's supposed to be. |
| Spokje |
I'm not sure how we are able to say "It works". What would be the definition of that?We have working tests? That should be the case?We have a "real" website that actually uses the module and make sure it works with the Contrib incarnation?If that's the case where do we get such a site and how we can we be sure "everything" works the same. |
| catch |
The last time we tested quickedit was when we originally thought it was ready to remove - months ago. Then we found various completely untested integrations with it that were still in other core modules. |
| Spokje |
Install D9 with the core module configured and containing data.Basically I'm unsure where the "data" is coming from in this example |
| catch |
It now doesn't work not because it was broken when it was removed (apart from those other core untested integrations) but because it's fallen behind with core deprecations in the meantime. If we'd known in advance there were another 20 issues in the way we'd not have created the contrib module when we did, but no-one expected to find dozens of untested integrations with it all over core. |
| catch |
However updating the contrib version with the commits from 10.x should bring it up to date with everything again. It's a fairly unique case because it was the first but also the hardest deprecation issue and we now know better than to create contrib modules before all the other steps. |
| Spokje |
Again, I'm fully with you that "it has to work", just want to define how we can be sure "it works". |
| catch |
Forum is an example where there's actual data. |
| catch |
So it'd be something like hack forum out of core (or apply the patch to remove it), install contrib forum, make sure the forum index is OK. |
| Spokje |
Yeah, but that's no where near completion and still wouldn't make sure the other modules "just work" |
| catch |
No but it's an example of where there's actual data to test. |
| Spokje |
Yeah, agreed, but we're looking at a majority of modules with no data IIRC |
| Spokje |
Which I would also like to have a definition on "just works" before we send somebody off to do the deprecation/removal dance all over again. |
| xjm |
The specific manual testing would depend on the specific module. We would report any regressions, and decided what to do about them. |
| xjm |
Like if you get a fatal error -- it didn't just work. If your theme's color settings got messed up -- it didn't just work. If your forum data are missing -- it didn't just work. |
| Spokje |
Which would mean we need (IMHO):a real website using the actual modulea real person willing to do the manual testinga real person willing to use its actual website for testinga real person knowing and using on its site just about any functionality available by the module.To me this seems like a big ask and a small chance we're going to find such a person/site. |
| xjm |
It can be a test module |
| xjm |
IT doesn't need to be a real site |
| Spokje |
I don't think we can manually cover all and any functionality |
| Spokje |
So where do we get a testsite with actual data? |
| xjm |
I feel like you're deliberately being pedantic and argumentative |
| Spokje |
Right I'll just stop here then. |
| xjm |
Plenty of people can manually test things with common sense limitations. |
| xjm |
We do it all the time |
| xjm |
If it's not for you, then don't do it. |
| Spokje |
Absolutely right, and good luck with that. |
| xjm |
I did find and recruit someone to do the needed testing for Place_Block and it was very helpful and uncovered issues. And that was just a very trivial module. |
| xjm |
OK, they left channel, whatever. (edited) |
| xjm |
Manual testing is still a thing people do. |
| dww |
Before we get too nasty with each other, let’s remember a few things:Spokje (and his buddy, Sisyphus) has been an absolute champ dealing with all the twists and turns of this incredibly hard and weird process that we’ve been figuring out as we go.Release managers are doing a great job trying to keep us honest and ensure core releases aren’t a $hitshow. We’re (rightfully) spending core contributor pain and suffering to avoid end users pain. It’s the deal with the devil we all make if we want to contribute to core. :wink:It can be extremely frustrating and disheartening to spend hours of time and life energy, thinking you’re seeing light at the end of the tunnel, only to discover that’s actually an oncoming train. :sweat_smile:We’re all doing the best we can, given difficult circumstances. Saying “I’m burned out, and don’t want to keep pushing this rock uphill” !== “ragequit”. (edited) |
| dww |
(Wtf, slack formatting?) |
| dww |
Oh crap, and too late — Spokje already left the channel. :cry: |
| Björn Brala (bbrala) |
That is quite sad. :cry: |
| dww |
I sent a private message to at least share the above with him, and give him some love and encouragement. Doesn't mean as much coming from me, but hopefully it helps a little... |
| xjm |
Hey folks, it was brought to my attention that saying rm -rf above made it sound like I was trivializing the work that goes into these ridiculously difficult issue chains. I actually meant it literally as a testing step for the D10 upgrade, as in, we don't need to test the whole removal; we just need to test it not being in the codebase after core's sufficiently cleaned up for that not to fatal. |
| xjm |
Sorry if it sounded like I was making a joke about the value of your work; I definitely didn't meant to do that. |
| xjm |
@dww Leaving in the middle of a discussion is ragequitting. I'll edit what I said though. |
| Spokje |
Returning after sleeping on the discussion is rage-returning? :innocent:Anyways: xjm reached out and we agreed it wasn't our best moment (or at least I agreed it wasn't my best moment).I was getting way to overprotective on the deprecation/removal issues and somehow good arguments were lost in what was more an exchange of random sentences than a discussion in the end IMHO,Let's move on and get this show on the road (or rather get these modules off the road, in a way that doesn't break any upgrade/migration path to the Contrib incarnations).I will try to keep a bit more distant from those issue, but me being me there's a pretty good chance I at least will have an "opinion" on things. I will however try to keep it a bit more sensible and friendly.Again thanks @xjm for reaching out and also very much so thanks @dww, @larowlan and @Gábor Hojtsy (he/him) who all individually reached out as well and all said Sensible Stuff.For those who want to try and remain sane during Core Contribution I can recommend watching the old but still very valid session from larowlan where ancient dinosaur technology like IIRC is being mixed with sensible advice on how to keep your cool Aussie-style during all the madness than can be Core Contribution.https://www.youtube.com/watch?v=leE5tH1wCQg |
| Björn Brala (bbrala) |
So glad you guys worked things out :slightly_smiling_face: :heart: Life is hard sometimes. |
| xjm |
I am absolutely adding "rage-returning" to my vocabulary :heart: |
| xjm |
And yeah, I think we both sort of caught each other at a bad time and weren't either of us at our best |
| Spokje |
Heh, #d10readiness, where vocabularies, codebase and patience are expanded beyond believe |
| quietone |
the step to perform manual testing was added to the policy on 12 April, https://www.drupal.org/node/3266744/revisions/view/12607372/12612234. It could some more detail. I haven't yet checked the issues to see if this step is included but I will over the day. |
| Spokje |
Thank you (and welcome back!) |
| quietone |
Thanks! It is nice to be here again. Still weak though so taking it slow, |
| Spokje |
No need to rush (at least on this one), there's some blocking stuff in front of it anyway. |
The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.
Comments
Comment #2
gábor hojtsyComment #13
gábor hojtsySaving notes.
Comment #15
gábor hojtsyThanks all!