[RFC] new feature prepare-migration

[legalsylvain]

Hi all,

I'm migrating a lot of time OCA or custom modules. Some action are very repetitive, and sometimes migration are trivial in fact. For that purpose, I began to develop a lib named odoo-module-migrate. (OCA discussion, GRAP repository)

I was thinking about the possibility to have a new command : ocabot prepare-migration MODULE_NAME FROM_VERSION TO_VERSION that could be called in the issues of each revision. (like this one)

this call could :

• create a new branch 13.0-MIG-MODULE_NAME
• call git command to recover code with format-patch syntax (ref)
• apply changes, calling the lib odoo-module-migrate
• propose a new WIP PR
• link the PR to the issue "Migration to version XX". (based on that work)
• ping the maintainers (this action should be automatic)

So, after that two options.

• the migration is enough, and after Code Review or functional review by runbot, an ocabot merge can be performed.
• some work should be done to make the PR working and the user that called the command ocabot prepare-migration should finish the work.

Just an idea. I think that it could make easier the migration of a the oca code base, each year, specially between two revisions that are very similar. (For instance, it doesn't seems that Odoo 14 is introducing a lot of changes. (except for web / pos modules) with OWL use).

Questions :

• do you think it is interesting to work on that feature ?
• if yes, I have not a clear idea how to give write access to the branch created by the bot for the user that call the command.

Thanks for your review.

[pedrobaeza]

The main problem as you depicted is that the created branch can't be accessed by possible migrators due to permissions, so I see that more as a local tool than a bot one. You can give specific permission to the one raising the command, but even that way, it's not very intuitive and avoid teams like mine to work collaboratively in a migration.

[sbidoul]

55 is also blocked due to the permission issue.

[yajo]

Can't you set the PR as "Allow edits from maintainers" so PSC are able to do changes?

[pedrobaeza]

The problem is that not only maintainers/PSC can migrate modules

[legalsylvain]

You can give specific permission to the one raising the command

@pedrobaeza : did'nt found how to give access to a specific branch. could you point how it's possible ? If it's possible to give access to one people, it is possible for many, don't you think ? In that case, maybe we could imagine a command like ocabot prepare-migration MODULE_NAME FROM_VERSION TO_VERSION [TEAM_OR_PEOPLE]. that case, if TEAM_OR_PEOPLE == Tecnativa, we can give write access to all the members of Tecnativa..

Apart of the write access problem, do you think, this feature is interesting ?

[pedrobaeza]

Well, manually you can go to the fork and give permissions, but I don't know how to do it via API. I still think this doesn't worth to be developed as a bot feature, but as a local tool.

[yajo]

If it's possible to give access to one people, it is possible for many, don't you think ?

I was talking about this feature that you can find in your PRs:

But if you really are able to do that, then it all becomes much easier. You can set TEAM_OR_PEOPLE == $original_pr_author,$original_pr_merger,$psc_members and you're done.

Apart of the write access problem, do you think, this feature is interesting ?

I think this is a need. The more time that passes without it, the more unmaintainable OCA becomes.

[pedrobaeza]

As said, the problem with any of that options is that you exclude to people that wants to migrate a module and they haven't been around before. I don't like also to have a lot of crap PRs of modules that:

• no need to be migrated.
• aren't going to be migrated by different reasons.
• refactoring is needed.

I see more maintenance with that PRs than doing manual steps when you want to migrate a module. And let's be honest, newcomers are going to have the same "barriers" with or without this.

[yajo]

But if someone adds a patch to a module in v13, it would be quite easy for the maintainer to do: /ocabot port patch 12.0 14.0 15.0

Then the bot:

1. migrates the patch
2. does a pre-commit run -a, just in case there are new pre-commit rules in those branches.
3. opens those pr for those branches
4. autoissue a /ocabot merge patch
5. if it suceeds, done!
6. if it fails, ping the original pr author and whoever gave him the order to do those ports

You assume point 4 will never happen, but that's simply assuming too much. Just check at how odoo fwport bot does it, it works most of the times. Even if it fails, you already have:

1. the pr open
2. the code reformatted (if needed)
3. the ci logs
4. the notification in your inbox (that acts as a reminder, so you won't forget to do the bw/fw ports, like it happens today)

In the worst case, you just go and close that pr, so what's the deal? :shrug:

I see only benefits :thinking: . Not having that is actually a big problem, so yes, let's continue with this feature! :blush:

[pedrobaeza]

You are mixing things as this issue is not about that.

[yajo]

I see, the flow described in the issue description is a bit different, but I don't see I'm drifting away too much here. :thinking:

Well, anyways, :+1: to this.

[pedrobaeza]

Yes, they are parallel things, but I'm not sure of both. Any way, if any other want to work on it, we can try and I hope I'm wrong and this proves to be very useful.

[legalsylvain]

But if someone adds a patch to a module in v13, it would be quite easy for the maintainer to do: /ocabot port patch 12.0 14.0 15.0

discussion opened here : https://github.com/OCA/oca-github-bot/issues/55