>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3314184. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <h2>Transcript</h2> <h2>0&#65039;&#8419; Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Tim from the DA in Portland, OR - keeping track of how we can support this initiative, and helping to organize meetings.</td> </tr> <tr> <td>thejimbirch</td> <td>Jim from Kanopi Studios.&nbsp; Cape Cod, MA. Love to help move this initiative along.</td> </tr> <tr> <td>Kingdutch</td> <td>Alexander from Open Social in the Netherlands. Following along on the progress.(splitting my attention between Slack and ViteConf today)</td> </tr> <tr> <td>alexpott</td> <td>alexpott, core committer, initiative lead</td> </tr> <tr> <td>m.stenta</td> <td>Mike Stenta from farmOS distro! &#128578;</td> </tr> <tr> <td>konfuzed</td> <td>Michael Sheldon from Georgia Tech, interested in anything that can help our EDU mess :smile:</td> </tr> <tr> <td>nerdstein</td> <td>Adam Bergstein from Pennsylvania</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Bob here from St Charles IL</td> </tr> <tr> <td>UjjwalAhluwalia</td> <td>Ujjwal Ahluwalia from Houston, TX. :wave:</td> </tr> <tr> <td>leslieg</td> <td>Leslie checking in late from Boston MA</td> </tr> <tr> <td>bircher</td> <td>Fabian, also checking in late</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>I arrived with Fabian's car, so also checking in late &lt;.&lt;</td> </tr> <tr> <td>briangilbert (realityloop) (he/him)</td> <td>:wave: Melbourne, Australia represent</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Is today too late to look things over?</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Not at all</td> </tr> </table> <h2>1&#65039;&#8419; Do you have any topics to propose for the meeting today? Feel free to propose them in this thread, and then I will give them their own unique threads for discussion. Conversation moving slow? Go ahead and open your own thread in the next numeric order.</h2> <table> <tr> <td>thejimbirch</td> <td>We've had a lot of people join since DC.&nbsp; I would like to suggest some more project overview topics.</td> </tr> <tr> <td>thejimbirch</td> <td>2. There is a roadmap in the Drupal Core Ideas issue queue that hasn't been updated since earlier this year.&nbsp; Can we move Distributions and Recipes initiative overview and roadmap to Distributions and Recipes initiative for better clarity?</td> </tr> <tr> <td>thejimbirch</td> <td>3. Adding a Plan issue to our issue queue with priorities about which features and issues should be tackled next.&nbsp; Some nice examples: <a href="https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/docs/ROADMAP.md">https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/docs/ROADMAP.md</a> and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/metatag/issues/3272774" title="Status: Closed (fixed)">#3272774: Plan for Metatag 2.0.0</a></span></td> </tr> <tr> <td>thejimbirch</td> <td>I bet if we had more of that outline mapped, we could get more contribution from all the folks that keep joining.</td> </tr> <tr> <td>alexpott</td> <td>So our big issues to tackle next are the same as last time:1&#65039;&#8419; default content in core2&#65039;&#8419; recipe composition - we&rsquo;ve come to the conclusion that just listing other recipes won&rsquo;t do3&#65039;&#8419; (and new for this week) recipe translationThere&rsquo;s been no progress really to report. Add all these issues are hard.</td> </tr> <tr> <td>thejimbirch</td> <td>"all these issues are hard" would be a good t-shirt</td> </tr> <tr> <td>alexpott</td> <td>We do have a roadmap <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_roadmap.md">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_roadmap.md</a></td> </tr> <tr> <td>alexpott</td> <td>It&rsquo;s missing 2&#65039;&#8419; and 3&#65039;&#8419;</td> </tr> <tr> <td>alexpott</td> <td>I will update later today</td> </tr> <tr> <td>alexpott</td> <td>Another task that would be awesome is some contribution instructions</td> </tr> <tr> <td>alexpott</td> <td>I will create an issue for that and add it to the roadmap too</td> </tr> <tr> <td>thejimbirch</td> <td>Please assign that one to me.</td> </tr> <tr> <td>nerdstein</td> <td>could that roadmap be translated to a "plan" issue and unknowns/discussions defined?</td> </tr> </table> <h2>2&#65039;&#8419; There is a roadmap in the Drupal Core Ideas issue queue that hasn't been updated since earlier this year.&nbsp; Can we move Distributions and Recipes initiative overview and roadmap to Distributions and Recipes initiative for better clarity?</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Raised by @thejimbirch</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Per @alexpott&nbsp;We do have a roadmap <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_roadmap.md">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_roadmap.md</a>(edited)</td> </tr> <tr> <td>thejimbirch</td> <td>So we have one in code, and one in the Drupal core ideas issue queue.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>One should reference the other most likely..</td> </tr> <tr> <td>hestenet (he/him)</td> <td>If the one in code is source of truth, the other locations should be updated to point to that.</td> </tr> <tr> <td>hestenet (he/him)</td> <td>(IMO)</td> </tr> <tr> <td>alexpott</td> <td>Yep one is easier to manage than two</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>So are we all in agreement there should be one Roadmap for Drupal Recipes. Calling the question.I would vote for the one in the codebase</td> </tr> <tr> <td>hestenet (he/him)</td> <td>If that's the one that the people most involved are more interested in updating, I would agree.</td> </tr> <tr> <td>bircher</td> <td>I am always in favour of having all text in git. But if it helps discoverability or is less intimidating for contribution I would prioritise that.</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Probably having an issue that points to the md roadmap in git is best, no need to have all the info in both. The issue can just be there for discoverability and suggestions.</td> </tr> </table> <h2>3&#65039;&#8419; Adding a Plan issue to our issue queue with priorities about which features and issues should be tackled next.&nbsp; Some nice examples: <a href="https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/docs/ROADMAP.md">https://git.drupalcode.org/project/schemadotorg/-/blob/1.0.x/docs/ROADMAP.md</a> and <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/metatag/issues/3272774" title="Status: Closed (fixed)">#3272774: Plan for Metatag 2.0.0</a></span></h2> <table> <tr> <td>hestenet (he/him)</td> <td>Raised by @thejimbirch</td> </tr> <tr> <td>nerdstein</td> <td>i think this could be an important enabler to getting more interested people participating</td> </tr> <tr> <td>thejimbirch</td> <td>Are there similarities between post 2 and 3 here?</td> </tr> <tr> <td>thejimbirch</td> <td>Are the roadmap and plan two different things?</td> </tr> <tr> <td>nerdstein</td> <td>i think they should be one in the same, personally</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Yeah, that's fair.</td> </tr> <tr> <td>nerdstein</td> <td>i would be happy to riff on a format for it. i think the most important info are: issues, points of discussion/decisions to be made, and a clear "status" of the effort</td> </tr> <tr> <td>hestenet (he/him)</td> <td>:plus_one:</td> </tr> <tr> <td>nerdstein</td> <td>The issue assignment will be helpful to see who is doing what</td> </tr> <tr> <td>nerdstein</td> <td>@hestenet (he/him) if you want to chat about some sort of format and/or organization of this all, let me know</td> </tr> <tr> <td>hestenet (he/him)</td> <td>TBH - it's almost exclusively the meetings I've been focused on supporting, for my part. I'd be more than happy to empower you to run with restructuring. I can grant permissions as needed.&nbsp;(edited)</td> </tr> <tr> <td>nerdstein</td> <td>maybe @thejimbirch @alexpott and i can brainstorm. happy to dive in if its welcomed but i would prefer a team effort</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Agreed - and I'm happy to chime in on any ideas for sure - just running all over the place :upside_down_face:</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Did go ahead and grant you maintainer/editing rights to: <a href="https://www.drupal.org/about/core/strategic-initiatives-distributions-and-recipes">https://www.drupal.org/about/core/strategic-initiatives-distributions-and-recipes</a></td> </tr> <tr> <td>hestenet (he/him)</td> <td>And the corresponding project - at least we won't be blocked on access to make changes once we sort through ideas &#128578;</td> </tr> <tr> <td>alexpott</td> <td>V happy to add more maintainers to the project</td> </tr> <tr> <td>nerdstein</td> <td>@thejimbirch Want to meet and discuss some ideas?</td> </tr> <tr> <td>thejimbirch</td> <td>yes!</td> </tr> <tr> <td>thejimbirch</td> <td>Lets include @bsnodgrass (he/him) also. re :2:</td> </tr> <tr> <td>hestenet (he/him)</td> <td>:clock11: It's just about meeting time! Kicking off things a couple minutes early here..</td> </tr> </table> <h2>4&#65039;&#8419; Both of the topics above would help provide guidance, allowing us to get new contributors involved.</h2> <table> <tr> <td>hestenet (he/him)</td> <td>Raised by @thejimbirch</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Per @alexpott part of the above would also be to create contribution instructions, which @thejimbirch has offered to take once the issue is created.</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Given <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/3283151" title="Status: Closed (fixed)">#3283151: Finalise the name for Drupal recipes</a></span></td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I should change <a href="https://www.drupal.org/project/drupalrecipesand">https://www.drupal.org/project/drupalrecipesand</a> make appropriate update in a bunch of references. Can someone suggest how I get that done?This may be a topic for another day, but I would like to get this done soonish!&nbsp;(edited)</td> </tr> <tr> <td>alexpott</td> <td>@bsnodgrass (he/him) tell me what permissions you need an I will given them to you &#128578;</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>@alexpott I'm not sure.. I think I will need to change the URL alias for the project?</td> </tr> <tr> <td>thejimbirch</td> <td>Is that still an active endeavor @bsnodgrass (he/him)?</td> </tr> <tr> <td>alexpott</td> <td>So I think we will need a task list added to an issue&hellip; where we work out who can do things&hellip; renaming tags requires people who work for the DA&hellip; wink wink @hestenet (he/him)</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Heh - task list ++ and I can do the DA-only type stuff for sure</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Sorry got stuck on the phone (some of us still use those). @thejimbirch we are discussing what to do with the work we did in the Fox Valley Drupal users group getting the ideas some traction. Maybe we can find a way to recast our efforts to support this initiative. Open to ideas!</td> </tr> </table> <h2>5&#65039;&#8419; Major priorities</h2> <table> </table> <h2>5&#65039;&#8419; 1&#65039;&#8419; Default content in core</h2> <table> <tr> <td>alexpott</td> <td><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/drupal/issues/2094481" title="Status: Closed (fixed)">#2094481: Support default content entities</a></span></td> </tr> <tr> <td>thejimbirch</td> <td>This is an issue in Drupal core.&nbsp; Do we need to identify tasks that are outside of the contrib recipe project?</td> </tr> <tr> <td>bircher</td> <td>yes I think we should, this may not be the only issue that could move on its own in parallel in core</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Also. If I understand it correctly, the initiative is planning to take over content import for core right? (Demo content not migration scale)</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Reading through the issue and larowlan's blogpost, I think that as of now, most of the mentioned issues are already solved one way or another in the default_content module. I will add a comment in the issue, with some thoughts</td> </tr> </table> <h2>5&#65039;&#8419; 2&#65039;&#8419; recipe composition - we&rsquo;ve come to the conclusion that just listing other recipes won&rsquo;t do</h2> <table> <tr> <td>alexpott</td> <td>There are a few issues in this area - I&rsquo;m not sure that there is yet a single one that scopes out what @bircher and I decided in Prague. <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-17"><a href="https://www.drupal.org/project/distributions_recipes/issues/3311249" title="Status: Closed (outdated)">#3311249: Dependencies difference on unchanged configuration throws does not match exception</a></span></td> </tr> <tr> <td>bircher</td> <td>yea but I am not sure now that what we discussed in Prague is even enough.</td> </tr> <tr> <td>bircher</td> <td>a recipe needs to be able to specify recipes for its ingredients to be composable. but more than recipe per config item we need a way for recipes to decide that they don't need to do anything.</td> </tr> <tr> <td>bircher</td> <td>so a recipe providing a role won't check if the role exists and is exactly the same as it provides already, but rather it checks if the role exists and considers itself "applied"</td> </tr> <tr> <td>bircher</td> <td>But I guess it also depends on where we want to have this control</td> </tr> <tr> <td>bircher</td> <td>for example the article recipe can say: "oh the editor role doesn't exist? run the editor recipe first! Then I am adding permissions to the editor" The canonical example. but that only works if recipes are very small. But if we have a bigger recipe to set up umami for example it will not just be a role with a permission but it will be fields and views and date formats and input filters etc. So either the default is to not fail when a recipe is run again or we need to make sure recipes are not run when they are twice in the tree</td> </tr> <tr> <td>bircher</td> <td>noting of course that running the whole umami recipe on top of minimal should produce the same as running first only parts and then more etc.. so not all the recipes in the same "request"</td> </tr> <tr> <td>nedjo</td> <td>An alternate way of addressing these issues could be what's captured in <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/drupal/issues/3307646" title="Status: Active">#3307646: Merge in config updates when (re)applying a recipe</a></span>. See that issue for notes on why as currently implemented reapplied recipes "will fail when any of three commonly occurring situations apply" and how we might be able to resolve those failures by merging in changes instead. The basic pieces expand on what's in Configuration Synchronizer and related contrib modules (which have had a modest uptick in usage in the past year, <a href="https://www.drupal.org/project/usage/config_sync">https://www.drupal.org/project/usage/config_sync</a>). Among other advantages, merging in available changes could mean we wouldn't need to further complicating the recipe format.So either the default is to not fail when a recipe is run againOverall, yes, I think we're better off focusing effort on finding ways to support reapplying recipes rather than introducing ways to avoid it.</td> </tr> <tr> <td>bircher</td> <td>@nedjo well but the problem is that we would then have to keep a copy of the config from the last time the recipe has been applied. Snapshotting the active config from before the recipe was run won't be enough. And I don't think that would be very practical but I could be wrong.</td> </tr> <tr> <td>kclarkson - (He/Him)</td> <td>Nothing to add here but love seeing @bircher and @nedjo thinking through this out loud. :grinning:</td> </tr> <tr> <td>bircher</td> <td>also @nedjo I don't think they are contradictions. a recipe when applied may decide "all good, there is nothing for me to do here" or maybe it could say "oh the config I wanted to add is already here, but I am going to make sure this property is set in a certain way on it"</td> </tr> <tr> <td>bircher</td> <td>I think we should design it such that we do not keep any state of the recipe around</td> </tr> <tr> <td>bircher</td> <td>so that for example a recipe could be "applied manually" (ie the dinner recipe calls for a pumpkin soup, but I decide to freestyle the pumpkin soup before applying the dinner recipe)</td> </tr> <tr> <td>nedjo</td> <td>I see the case for supporting advanced uses like freestyling but I think our challenges at this point are to get the basic and most common use cases working. I think that most common use case when applying a recipe is pretty much "give me the latest", which translates as merging in available changes.the problem is that we would then have to keep a copy of the config from the last time the recipe has been appliedAgreed, I think we absolutely need that, roughly the same as we do with staged config. It was always going to be needed to be able to merge in config updates, but AFAICS with config actions in the mix snapshotting is needed just to get our current code (has this config object changed since it was applied?) working. The issue for that is <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-1"><a href="https://www.drupal.org/project/drupal/issues/2960870" title="Status: Active">#2960870: Snapshot configuration as installed and updated from recipes and extensions</a></span>.</td> </tr> <tr> <td>bircher</td> <td>@nedjo don't get me wrong: I would love to get merging of config into core! But I think that is really hard, there is a whole list of deeper problems that would have to be solved first. For example in order to merge config we need to be able to sort it, we are already halfway to sortability, but most sequences currently have no sorting and there is resistance by some that want to disable sorting for some sequences altogether. This on its own is already a lot of work. Then diffing and merging on its own has some non trivial code needs for sequences (especially arrays of arrays is "fun").Making this all a prerequisite for "basic" recipes seems like a very steep path, I would prefer if the recipe system does not stand in the way of these things, yet has smaller, achievable milestones on the way. And it seems to me that "not failing very hard" when a recipe is encountered which may have been applied or which may have been manually set up. (or by a recipe of a different name etc) is a much more attainable first goal.</td> </tr> <tr> <td>bircher</td> <td>I guess the challenge is then to determine what to do. We already have some of these things but maybe it would be worth having a setting to define the default for all the config in /config.Possible things we want to do:just ensure it exists - ok if the config exists in any stateensure it is exactly the same - copy over the provided config and override existing onecopy the config or set some values if it exists alreadyfail if it exists and doesn't match exactlyfail if it exists and some properties are not as expectedgo and do complicated things - comparing against some snapshot and do diffing and merging, or other custom things depending on a remote API etc..</td> </tr> <tr> <td>nedjo</td> <td>@bircher hey, I'm the last person to suggest any of this is simple :wink: But what strikes me is that to reliably achieve even just the tiny bit we're already trying to do - answer the question, "is the version of this config item we have in the active storage the same as what was provided by recipe(s)?" - we need pretty much all that complexity.diffing and merging on its own has some non trivial code needs for sequencesYes, in config_merge we decided we couldn't reliably merge sequences and needed to instead replace one with another, see <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-3"><a href="https://www.drupal.org/project/distributions_recipes/issues/3301370" title="Status: Closed (duplicate)">#3301370: Model core's standard install profile as recipes</a></span> and see where all things break. I started in on the exercise, hoping I might be able to hand it off. I also drafted a bunch of relevant documentation at <a href="https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_author_guide.md">https://git.drupalcode.org/project/distributions_recipes/-/blob/1.0.x/docs/recipe_author_guide.md</a>.</td> </tr> <tr> <td>bircher</td> <td>@nedjo Yea same analysis different solution in config_split: <a href="https://git.drupalcode.org/project/config_split/-/blob/2.0.x/src/Config/ConfigPatchMerge.php#L305-376We">https://git.drupalcode.org/project/config_split/-/blob/2.0.x/src/Config/ConfigPatchMerge.php#L305-376We</a> transform the numeric sequence keys to something non numeric that survives shuffling which we can then compare. You can even extend the config schema to define your own way.But also [#3298341]answer the question, "is the version of this config item we have in the active storage the same as what was provided by recipe(s)?" I agree that all this is needed to answer that question. I am questioning if it is necessary to ask this question.</td> </tr> <tr> <td>nedjo</td> <td>I agree that all this is needed to answer that question. I am questioning if it is necessary to ask this question.Definitely worth the exercise. And, obviously, I wasn't in Prague and so I'm missing some key context here.I get we can determine it's not necessary to apply another recipe when two conditions are true:1. The only reason to apply the other recipe is to meet a set of config requirements.2. Those config requirements are already met.What I'm not yet seeing is how this no-op reduces scope, since it seems like we still have the contrary cases.</td> </tr> </table> <h2>5&#65039;&#8419; 3&#65039;&#8419; (and new for this week) recipe translation</h2> <table> <tr> <td>alexpott</td> <td><span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-13"><a href="https://www.drupal.org/project/drupal/issues/3313863" title="Status: Needs work">#3313863: Translation of recipe input and config actions [monolingual]</a></span></td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>May I say that translation in drupal is a hussle already....Config translation is the issue is you ask me, I mean... the thought was into a right direction, but I think the implementation did end up not being really scalable.</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>The issue refers to the translations of config actions only... but should we be also thinking if/how config translations will be supported by recipes?</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Although I am not sure if this is in the scope of the initiative and if similar discussions have been made before &gt;.&lt;</td> </tr> </table> <h2>6&#65039;&#8419; Drupalcon Pittsburgh plans</h2> <table> <tr> <td>alexpott</td> <td>Did anyone submit a talk? @thejimbirch</td> </tr> <tr> <td>hestenet (he/him)</td> <td>(I did not)CFS deadline is monday</td> </tr> <tr> <td>thejimbirch</td> <td>I did.&nbsp; I submitted a panel talk.&nbsp; Invited @nerdstein to co-host.</td> </tr> <tr> <td>thejimbirch</td> <td>definitely would love more developer contributors to join us.&nbsp;(edited)</td> </tr> <tr> <td>nerdstein</td> <td>thanks for the invite, i just wrote a draft description</td> </tr> <tr> <td>nerdstein</td> <td>but eager to help out more, too</td> </tr> <tr> <td>G&aacute;bor Hojtsy (he/him)</td> <td>Panels are supposed to be slide-less mind you :)</td> </tr> <tr> <td>thejimbirch</td> <td>Oh, I may have messed that up then.</td> </tr> <tr> <td>thejimbirch</td> <td>I was able to change it!</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>I'm glad to help out on this as well. I will be Pittsburgh</td> </tr> <tr> <td>bsnodgrass (he/him)</td> <td>Is there a public link for it @thejimbirch</td> </tr> <tr> <td>G&aacute;bor Hojtsy (he/him)</td> <td>Sessionize submissions are not public unfortunately</td> </tr> <tr> <td>thejimbirch</td> <td>Here's a screenshot</td> </tr> </table> <p>Participants:</p> <p>hestenet, thejimbirch, Kingdutch, alexpott, m.stenta, konfuzed, nerdstein, bsnodgrass (he/him), UjjwalAhluwalia, leslieg, bircher, Marios Anagnostopoulos, briangilbert (realityloop) (he/him), nedjo, kclarkson - (He/Him), G&aacute;bor Hojtsy</p>