Migrations should not be configuration entities

The last time I asked that people got angry ... I am glad that we realize that a migration is something for a developer only, not related to site building at all. I guess we could just go with a migration folder inside modules + the wonderful yaml discovery component.

Yeah agreed, it's currently very ugly to write/test migrations outside of tests.

Just like we have dynamic local_tasks and routes, we can support a similar callback as we have there or simply an alter hook or event and if someone wants to build a UI, he can define his own config entity just for user provided migrations and provide them through such a method.

- It is true that migrations would not include text to be translated except maybe the label of the migration but that is secondary since we don't translate update function descriptions either (@webchick's example)?

- Mike Ryan pointed out to me in email that "I will say that for me the ability to implement creating/editing/deleting migrations through the UI (in contrib) is essential" @berdir outlines a plan for satisfying this without making every migration a config entity above.

Looks like the DX of developing migrations is greatly hindered by the fact that its config and therefore works with the copy-over-on-install-to-active-store-then-lives-its-own-life approach and then requires active config store hacking in development. I posted a comparison of static YAML and config among other things from the point of view of deployment, who writes them, etc. at https://drupal.org/node/2183957#comment-8756593 which may very well be useful here.

If I understood correctly, we want modules defining migrations in YAML files placed in a concrete folder.
E.g: migrate_drupal will have migrations/migrate_drupal.migration.d6_text_format.yml and so on.
The YamlDiscovery will detect and load those from every installed module.

From ConfigEntityBase, we need the following features:

• We will need hooks replaced the hook_entity_load(), so we can alter provided migrations from contrib modules: e.g. hook_migration_alter.
• We need a simple query system for groups: give me all the migrations related to d6|d7 or content|config. Groups should be flexible. E.g: contrib could provide d8 to d8 migrations, or I want the migrations related to monolingual sites. I'm not sure this will be that simple, is like duplicating (a simpler version of) EntityQuery.
• Migration class should be able of parsing the migration defined by an array given at the constructor.

Am I missing something?

Postponing this until we've made a clear decision over in #2183957: Provide configuration schema for Migration module