Drupal 8 Migrate in Core weekly meeting

https://plus.google.com/b/106269343178096590461/events/cmbcg3bm3nsq3dd18...

Meeting notes. Please make corrections below in the comments - sorry in advance for any mistakes!

benjy, phenaproxima, mikeryan, ultimike, alexpott, kdechant were present.

• Migrations need to use the configuration entity dependency system - alexpott started this patch. benjy thinks we should progress with this patch to fix some of the problems of trying to run migrations for things that aren't enabled. There are two sides to dependencies - module dependencies and migration dependencies. This patch is related to the former (mostly). The downside of this patch is that there is some duplication between module dependencies and migration dependencies in configuration.
• Move migrations to core modules (no issue or patch yet) - alexpott said that configurations would be removed when the migrate modules are uninstalled because they own the migrations, regardless of where the install config .ymls live.
• Migration groups - alexpott feels that d6 migrations will always be used only for d6, so why make them mutable by changing from "groups" to "tags" (I think I understand his argument - correct me down in the comments if I'm incorrect). He doesn't think the "group" should be changeable. There are use cases where the same migration can be used for both d6 and d7, so it would be handy to be able to apply tags to migrations dynamically. alex thinks there should be user-defined tags as well as unmutable "groups". mikeryan suggested adding a "source version" configuration parameter under the source plugin, everybody seemed to like this idea. This would go forward with the current patch, and a new patch for the version on the source plugin.
• Support shared configuration between migrate groups - if we proceed with the previous issue, then alex is good with moving forward with this patch. alex would like to see this patch updated so that when a migration group config is deleted, the config dependency system takes care of figuring out which other migration configurations need to be deleted as well. alex is also wondering if we're going to have any migration groups in core - the answer is that migration group configs would be created when a migration is run - assuming we go with a template system (see next item below). alex has some concerns with dependencies with this issue.
• Migrations should support non-installed default configurations (templates) - alex is generally in favor of this, but is concerned that this is something unlike anything else in core, and that there isn't any code behind it yet. He is concerned that this type of change will take a good amount of time to get in.

There was also a good bit of discussion about the pros/cons of bringing a UI into core in order to create migration group configuration entities. Another option is to not add a UI, but rather write a Drush command to configure a migration group. This was part of the discussion of what the best order of implementation of the various API changes that were discussed.

There was also some discussion about taking a step back and not implementing migration groups right away in core, but having them developed in contrib first. There seemed to be a lot of momentum in this direction. This would allow us to focus the core work on https://www.drupal.org/node/2460529 and moving migrations into core modules (and faking tests somehow).

• ultimike
• marvil07
• benjy
• chx
• eliza411

• Arabic
• Alappuzha
• Event Platform
• Western Ohio User Group
• Goa Drupal Community
• Liverpool
• Chandigarh Drupal Geeks (C.D.G.)
• API-First Working Group
• Compony opinionated developers
• 4SPOTS