Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] new feature prepare-migration #119

Closed
legalsylvain opened this issue Jun 1, 2020 · 13 comments
Closed

[RFC] new feature prepare-migration #119

legalsylvain opened this issue Jun 1, 2020 · 13 comments

Comments

@legalsylvain
Copy link
Collaborator

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
Copy link
Member

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
Copy link
Member

sbidoul commented Jun 1, 2020

#55 is also blocked due to the permission issue.

@yajo
Copy link
Member

yajo commented Jun 2, 2020

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

@pedrobaeza
Copy link
Member

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

@legalsylvain
Copy link
Collaborator Author

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
Copy link
Member

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
Copy link
Member

yajo commented Jun 2, 2020

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:

imagen

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
Copy link
Member

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
Copy link
Member

yajo commented Jun 2, 2020

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? 🤷

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

@pedrobaeza
Copy link
Member

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

@yajo
Copy link
Member

yajo commented Jun 2, 2020

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. 🤔

Well, anyways, 👍 to this.

@pedrobaeza
Copy link
Member

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
Copy link
Collaborator Author

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 : #55

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants