>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3314183. --> Reported by: [hestenet](https://www.drupal.org/user/54034) >>> <p>This meeting:<br> &#10148; Is for distribution developers, initiative contributors, the Drupal Association and anyone interested in the initiative.<br> &#10148; Usually happens every other Tuesday at 1600 UTC.<br> &#10148; Is done over chat.<br> &#10148; Happens in threads, which you can follow to be notified of new replies even if you don&rsquo;t comment in the thread. You may also join the meeting later and participate asynchronously!<br> &#10148; Has a public agenda anyone can add to.<br> &#10148; *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.</p> <p>ping: @mixologic @kingdutch @bircher @briangilbert @navneet0693 @Tiago Barreiro de Siqueira @Mohammed Razem @finn @dww @Aaron McHale @alexpott @kreynen @thejimbirch @dbosen @smccabe @thenchev @bsnodgrass @shawndearmond @nerdstein @konfuzed @dimkritsotakis @Rajab Natshah @sean.e.dietrich @UjjwalAhluwalia @joegraduate @m.stenta @leslieg @jpoesen @guptahemant (go to the meta issue to add or remove yourself from the list: <a href="https://www.drupal.org/project/infrastructure/issues/3269687">https://www.drupal.org/project/infrastructure/issues/3269687</a>)</p> <p>:thankful: I'd also like to take a moment to highlight our initiative sponsor! Discover Global Network has generously stepped forward to provide resources that are allowing the Drupal Association to make the necessary updates to modernize distribution support on Drupal.org. Feel free to check them out at: <a href="https://www.discoverglobalnetwork.com/">https://www.discoverglobalnetwork.com/</a></p> <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>bsnodgrass (he/him)</td> <td>Here from St. Charles IL, far western burbs of Chicago... Catching back up with the latest from DrupalCon (I was out of the office for a little vacation last week)</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>:wave: Marios Anagnostopoulos, here to get informed about next steps / issue prio etc..</td> </tr> <tr> <td>bircher</td> <td>:wave: Fabian Bircher here</td> </tr> <tr> <td>nerdstein</td> <td>:waves: Adam. Looking forward to hearing how DrupalCon Europe went.</td> </tr> <tr> <td>m.stenta</td> <td>Mike Stenta here (arriving late and catching up) from farmOS &#128578;</td> </tr> <tr> <td>penyaskito</td> <td>Christian located in Seville, Spain. Interested on being up to date with what&rsquo;s going on on the initiative and hoping I can help (classic post-DrupalCon enthusiasm)</td> </tr> <tr> <td>hestenet (he/him)</td> <td>Tim joining late after recording a podcast, from Portland, OR - thanks for running the meeting without me, Alex</td> </tr> <tr> <td>thejimbirch</td> <td>Jim checking in late also</td> </tr> <tr> <td>briangilbert (realityloop) (he/him)</td> <td>:wave: Joining from Melbourne, Australia</td> </tr> <tr> <td>alexpott</td> <td>:thankful: I&rsquo;d also like to take a moment to highlight our initiative sponsor! Discover Global Network has generously stepped forward to provide resources that are allowing the Drupal Association to make the necessary updates to modernize distribution support on Drupal.org. Feel free to check them out at: <a href="https://www.discoverglobalnetwork.com/">https://www.discoverglobalnetwork.com/</a></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>nerdstein</td> <td>Update on progress from DC Prague</td> </tr> <tr> <td>nerdstein</td> <td>General status update: where are we, what issues are open, what decisions need to be made, etc</td> </tr> <tr> <td>alexpott</td> <td>The priority target are 4&#65039;&#8419; and 5&#65039;&#8419;&nbsp; in the meeting</td> </tr> </table> <h2>2&#65039;&#8419; I&rsquo;ve RBTC&rsquo;d the name &ldquo;Recipes&rdquo; today <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> because it&rsquo;s been writ large across Drupalcon Prague and it came out really well. Both people with tonnes of Drupal experience and those relatively new to Drupal got what they were and how they would be useful.</h2> <table> <tr> <td>bsnodgrass (he/him)</td> <td>Yay!</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>At first glance the target functionality has similarities with symfony recipes so it will also make sense to symfony devs that are new to drupal.</td> </tr> <tr> <td>bircher</td> <td>I concur with Alex. All the people I talked to at Drupalcon Prague about this had no issue with the name.</td> </tr> <tr> <td>kingdutch</td> <td>I was involved in original naming bikesheds and at DrupalCon forgot this wasn&rsquo;t decided and embedded already, so big :heavy_plus_sign:1&#65039;&#8419; from me</td> </tr> <tr> <td>G&aacute;bor Hojtsy (he/him)</td> <td>+1</td> </tr> </table> <h2>3&#65039;&#8419; :tada: we had some new contributors to the initiative at sprint day - see <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/distributions_recipes/issues/3311451" title="Status: Closed (fixed)">#3311451: Recipes require PHP 8.1 but when applying on D9 the PHP minimum is PHP 7</a></span> @tasc</h2> <table> <tr> <td>Marios Anagnostopoulos</td> <td>:tada:</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>concerning #3311111, I wanted to pr to 1.x as well, but noticed that while the commit is there, If you try to merge to project/distributions_recipes:10.0.x The changes are reapplied.Does this have anything to do with the pipeline failing?</td> </tr> <tr> <td>alexpott</td> <td>@Marios Anagnostopoulos you have to change the branch the PR is against</td> </tr> <tr> <td>alexpott</td> <td>We default to 10.0.x because that&rsquo;s the norm</td> </tr> <tr> <td>alexpott</td> <td>What I do use git worktree&nbsp; to have a 1.0.x check out inside my 10.0.x checkout kinda at the same time. Ie. git worktree add 1.0.x still need to 2 PRs but it makes life a bit simpler</td> </tr> </table> <h2>4&#65039;&#8419; @bircher and I had a discussion that&rsquo;s very important about recipe composition. We&rsquo;re finding that a simple instruction to apply another recipe before applying this one is to hard and not how we need it to work. A recipe needs to be able to say I want this piece of config and if we don&rsquo;t have it use this recipe to make it. There&rsquo;s a summary of our discussion on <span class="drupalorg-gitlab-issue-link project-issue-status-info project-issue-status-7"><a href="https://www.drupal.org/project/distributions_recipes/issues/3306291" title="Status: Closed (fixed)">#3306291: Clarify recommended use case(s) for ensure_exists config action</a></span>#comment-14703762</h2> <table> <tr> <td>alexpott</td> <td>I think we need progress here before we continue our work on <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></td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Reading #comment-14703762 I understand that we assume that recipes will not override existing configuration. Is this a spec or just not a consideration for the mvp?</td> </tr> <tr> <td>alexpott</td> <td>I think at some point we should enable the user to choose and show them what will happen</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>That sounds very tricky though if we have 0 state management for the recipes.</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>And I understand that we aim for having no state management right?</td> </tr> <tr> <td>alexpott</td> <td>Well we know what change the current recipe wants to make. So we can ask the user then</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Still sounds tricky, since in larger projects, if someone wants to apply a recipe that overrides config they haven't added to the site themselves, it would be impossible to decide.</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>Unless we show some diff like @bircher mentioned (I think he also mentioned we could get inspiration from config_split for that)</td> </tr> <tr> <td>alexpott</td> <td>We plan to take a config snapshot before any recipe applying to allow reverting.</td> </tr> <tr> <td>Marios Anagnostopoulos</td> <td>oh so no interactive things, just apply the recipe -&gt; override stuff if enforced -&gt; check your site please -&gt; roll back or be happy?</td> </tr> <tr> <td>alexpott</td> <td>To be decided by doing and seeing what happens</td> </tr> <tr> <td>bircher</td> <td>I think it will be very difficult to know what a recipe does exactly. Especially if we allow actions via services etc. Since actions run php code it will be easiest to show a config diff and allow reverting</td> </tr> <tr> <td>bircher</td> <td>as it is with playing around with new modules the easiest way to roll back is to imoprt a previous database dump. and I am afraid that it will be necessary for some recipes that have too many side effects as well.</td> </tr> <tr> <td>bircher</td> <td>I think the cookbook example is pretty good:For making a Pizza Margherita you need a pizza dough and tomato sauce and mozzarella. Then there is a recipe for how to make pizza dough in case you don't have any. And a recipe for tomato sauce in case you need more. But you could create the Tomato sauce before when you made some pasta and re-use it. Or you could decide to make a pizza dough with a different recipe first.As for if we want to enforce how the config looks like, maybe we should make that configurable. Some recipes want a certain view to look a specific way others just cate that it exists and others just want to add stuff (permissions) to it if it does exist... They are all valid use cases I think, we should just make it easy to make recipes composable.</td> </tr> </table> <h2>5&#65039;&#8419; In the next two weeks I plan to have a meeting with @berdir about what he thinks about default content in core or how he would approach the issue. Berdir has done a lot of work on the default_content module v2 and core so is an ideal person to talk to. I will take notes and add them to <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> or one of the other interrelated issues.</h2> <table> <tr> <td>Marios Anagnostopoulos</td> <td>Does the current default content module handle custom entities (I would guess no)Is this something we would care to support?</td> </tr> <tr> <td>alexpott</td> <td>I don&rsquo;t think this is a requirement from the get-go</td> </tr> <tr> <td>berdir</td> <td>what exactly is a custom entity in this context?</td> </tr> <tr> <td>berdir</td> <td>it should support any content entity type and most field types, the only one that I'm aware of right now isn't working is layout builter, but there's a wip patch for that</td> </tr> <tr> <td>bircher</td> <td>I think the most interesting part of default_content for recipes is the (de-)serialisation. Ie how entities and fields are represented as yaml with enough data to re-create them.</td> </tr> <tr> <td>berdir</td> <td>that's more or less all it does &#128578; part of that is the dependency handling, so that entities that reference each other are imported in the right order.</td> </tr> <tr> <td>bircher</td> <td>yes but it also imorts/creates them on module install. And I think for recipes we would just need the "api" so to say. Calling to creating the content would be done in the code responsible for running the recipe rather than reacting on a module being installed.</td> </tr> <tr> <td>bircher</td> <td>and yes the entities referencing each other is an important aspect.</td> </tr> <tr> <td>berdir</td> <td>ok, that makes sense. I already did mention to @alexpott that one challenge is how to expose the export, because the contrib module only has a drush integration and no other UI or so</td> </tr> </table> <p>Participants:</p> <p>nerdstein, alexpott, bsnodgrass (he/him), Marios Anagnostopoulos, bircher, kingdutch, G&aacute;bor Hojtsy, Berdir</p>