Hello all, it’s time for the weekly migration initiative meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 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 here: https://www.drupal.org/project/drupal/issues/3113541
➤*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.
| mikelutz | #2746541: Migrate D6 and D7 node revision translations to D8 |
| mikelutz | I’ve started reviewing this one, there are a few outstanding questions about some fixture and test changes I made way back in my first proof of concept patch. I know I had reasons at the time, but I’m looking through before and after fixtures right now to try to remember specifics. |
| Gábor Hojtsy (he/him) | It would be really nice to see this land, as @quietone would be able to continue working on the entity translation one which is also needed to land before we can stabilise the migrate multilingual stuff |
| Gábor Hojtsy (he/him) | does @heddn have interest/time for this (too)? :slightly_smiling_face: |
| heddn | my biggest priority when I get some free moments is #3093652: Make migrate_upgrade compatible with Drush 10.. which is also a pretty big blocker for things too. |
| heddn | @benjifisher not UX, but possibly an area you could help is to get tests passing on ^. It would free up some time. |
| benjifisher | I will have a look. How hard can it be? (famous last words) |
| mikelutz | There has been some discussion about what the future of migrate is once Drupal 7 marketshare is sufficiently reduced and it no longer makes sense to maintain the Drupal 6/7 migrations in core. |
| mikelutz | I don’t actually believe that d7 marketshare will be low enough by Drupal 10 to remove the migrate_drupal module, but it will happen eventually. One of the thresholds we’ve used as to whether a feature goes in contrib or in core is whether it directly supports the core mission of providing Drupal 6/7 migrations into drupal 8, so what happens once that system is nol longer needed. |
| benjifisher | I saw a suggestion from Moshe that the Migrate API move back to contrib in D10. I guess that means he is volunteering. :wink: |
| mikelutz | The migration system has proved itself to be very useful in other ways, and I belive it has value in core as an api. It’s useful for pulling in data from all kinds of sources (though it could continue to do so in contrib) |
| heddn | well, in d10, it might make sense to use something like soong instead. too early to tell |
| mikelutz | I believe the best business case for keeping it in core would be as a system focused on pulling in data from other competing CMS systems. |
| heddn | having the destination plugins are pretty useful in core. and the base process and migration plugins. the source plugins for things besides the base sql could probably get deprecated |
| mikelutz | The biggest selling point of migrate is that it lowers the barrier to entry to Drupal when coming from some other system. Given the way our market share looks, I don’t think we can give that up or send it back to contrib. |
| mikelutz | But I do think it really changes what migrate looks like in the coming years. |
| mikelutz | Focusing on improving the robustness and usefulness of the API outside of just what core happens to currently use for d6/7 migrations (whether that is soong or not) |
| benjifisher | Is this a good summary of your suggestions?Keep the Migrate API (migrate module) in core.Consider removing migrate_drupal and migrate_drupal_ui modules to contrib when D7 market share drops "enough". |
| mikelutz | Well, also at some point to consider bringing more of migrate plus and tools into core, regardless of whether core migrations use things. I think to do that will require us to define a new threshold for what’s allowed, otherwise we risk a bloat of very specialized process plugins, among other things. |
| benjifisher | Right. The current criterion is to include things needed by migrate_drupal(). If we remove that module, then we need a new criterion. |
| benjifisher | Here is a half-baked thought: the new criterion could be to support migrations from JSON:API (the actual API, not the module that implements it in Drupal). |
| mikelutz | Not a bad thought, but migrate doesn’t do well with that type of a source at all right now. |
| mikelutz | With that being a top down get the parent, then find the references then the references of references while migrate likes to process the references first and associate them with a parent afterward. |
| andypost | 5c is that feeds making nice UI on top of migrate, so +1 to UI in contrib |
| kevinquillen | Better support for JSON/XML parsing and updating from, to handle ongoing migrations |
| kevinquillen | (similar to feeds but for migrate) |
| andypost | #2990289: [META] feeds_migrate Road Map |
| kevinquillen | Is this Feeds or Migrate though? I want to stick with MIgrate, and have no need of UI for it |
benjifisher, Gábor Hojtsy (he/him), heddn, wimleers (he/him), damienmckenna, hash, Joshua Turton (srjosh), mikelutz, andypost, kevinquillen