This meeting:
➤ Is for distribution developers, initiative contributors, the Drupal Association and anyone interested in the initiative.
➤ Usually happens every other Tuesday at 1400 UTC.
➤ Is done over chat.
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to.
➤ *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.
ping: @mixologic @kingdutch @bircher @briangilbert @navneet0693 @Tiago Barreiro de Siqueira @Mohammed Razem @finn @dww @Rajab Natshah (go to the issue of the next meeting to add or remove yourself from the list)
: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: https://www.discoverglobalnetwork.com/
0️⃣ Who is here today? Comment in the thread below to introduce yourself and tell us why you are joining us.
| Rajab Natshah |
Rajab, Technical Product Lead at Vardot. A maintainer of the Varbase distribution.Dreaming of having a Visual Distribution Operator/Manager in the Drupal.org |
| ronaldtebrake |
Ronald, maintainer of Open Social :slightly_smiling_face:Interested to see how we can help each other :blob_excited: |
| briangilbert (realityloop) (he/him) |
Brian, founder of Realityloop, maintainer of Foundry |
| dww |
Derek at TEN7. Mostly built the original bespoke d.o distro support, long-term interest in distros. Celebrating my 16th year on Drupal.org today. |
2️⃣ On the DA side, we are continuing precursor work for the Drupal.org support for the new distribution model. (per: #3252534: [Plan] Distribution support on drupal.org and packages.drupal.org)As we speak, we're working on some jenkins/GitLabCI/kubernetes configuration - because that aligns both with this initiative and our GitLab Acceleration initiative.We are working on multiple initiatives at once - so slow and steady will win the race.
| dww |
That's exciting when the same changes can benefit multiple efforts! :tada: Tricky times y'all are navigating. But yay for slow and steady. One of the Breema Principles is "No Hurry, No Pause". That's been a lot of support as a way of approaching things in my life. :smile: |
3️⃣ Level of nesting support for the Root composer.json with packages.drupal.org repository limited or unlimited nesting? 1,2,3 ...10 (
| hestenet (he/him) |
@Rajab Natshah Raised this point - I'm not sure I personally fully understand the question - can you maybe provide more detail? |
| Rajab Natshah |
Example issues are likeIssue #3165189: Fix missing composer.json file with "drupal/core": "^9" and core_version_requirement: ^9[#3165189] |
| Rajab Natshah |
If the module was required in:1st root composer.json ( no issues )2nd package with composer.josn ( no issues )3rd nested package ( now is the issue )not working in more nested composer levels---This is in Drupal 9.3.x + Composer 2.2.x + No composer.json file in the module + restreacted core_version_requirementIf the package was in https://packagist.org/ it will work. only having the issue with packages.drupal.org |
4️⃣ Is it better to convert all old Sub Profiles to Standalone profiles?Switch most custom classes/sub modules/themes to their own package/project too. Then assemble packages only in profiles. even the custom installer steps
| hestenet (he/him) |
Per @Rajab Natshah |
| dww |
:thinking_face: Generally sub-anythings have been tricky for d.o to get completely right. I see the appeal of putting every (module|profile|theme) into its own namespace / project, and then assemble it all via composer. But in some cases I really don't think that's practical, and it does make sense to keep shipping multiple sub-whatevers in the same package. Otherwise "no one" would ever find demo modules, extensions that not everyone needs that don't fit well as plugins or other lightweight conditional code paths, etc. So I believe it needs to be assessed case by case.That said, I haven't been maintaining a distro in ages. I'm not that versed in the current state of things. If there's a compelling reason that "all" subprofiles should be moved into standalone projects/profiles/packages, I'd love to understand more about it. ¯\_(ツ)_/¯ |
| kingdutch |
I think I’m still in the minority on drupal.org that thinks that composer.json is for shipping code and packages of code do not necessarily need a 1:1 relationship with a module/theme/profile.(this is similarly why I’m not a fan of the automatic creation of composer packages from submodules in module projects)Open Social contains lots of modules to make it flexible for different use cases. Versioning that across multiple repositories or even multiple composer packages would be a nightmare.They’re different parts of Drupal (i.e. different modules and themes) but they’re part of the same codebase and don’t work well outside of that context (i.e. single composer.json) |
| Aaron McHale |
In the context of distributions, I can't think of a use-case for a sub-profile, one wouldn't be able to use it right because the distro's profile installs itself |
| kingdutch |
Ah yeah I was more responding to dww than to hestenet :smile: I don’t know a use-case for subprofiles at the moment either. |
Participants:
Rajab Natshah, ronaldtebrake, briangilbert (realityloop) (he/him), dww, hestenet, kingdutch, Aaron McHale
Comments
Comment #8
hestenetComment #10
hestenet