1. Mailing Lists
  2. Contributors
  3. Re: Procedure to create 16.0 branches

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Procedure to create 16.0 branches

Re: Procedure to create 16.0 branches

Avatar

Re: Procedure to create 16.0 branches

by
Groupement Régional Alimentaire de Proximité, Sylvain LE GAL
- 20/07/2022 15:46:34
Hi Yann,

Well, it's a possibility. Another one is to developp a call like "robodoo r+" (Odoo SA tools), that (AFAIK) merge a PR and port and merge changes in other releases.

I don't know right now, and I'm not a git expert. but yes, some OCA tools could be developped, to make easier the maintenance of the changes in many release.

Stefan (Bidoul) do you have a point of view on this subject? I know that you want to update the changes of mis-builder on the different active branches of the repo.

Sylvain LE GAL - Twitter
GRAP - Service informatique (Groupement Régional Alimentaire de Proximité)
Site Web | FramaSphere | Facebook
3 Grande rue des Feuillants, 69001 Lyon
Standard : (+33) 09.72.32.33.17
Service Informatique : (+33) 09.73.79.64.40
Astreinte Informatique : (+33) 06.81.85.61.43
Member of the OCA (Odoo Community Association)


Le mer. 20 juil. 2022 à 15:42, Yann Papouin <notifications@odoo-community.org> a écrit :
Hello Sylain,

Regarding the described drawback, a possible solution would be to create a bot action to do an automatic cherry pick of every changes on a module in a branch N-1 until installable becomes True in the manifest of the module in the branch N ?
It would reduce the code drift until a migration is proposed.

--
Yann PAPOUIN, Ingénieur R&D | DEC


Le mer. 20 juil. 2022 à 15:02, Sylvain LE GAL <notifications@odoo-community.org> a écrit :
Hi Stefan,
Thank you very much for bringing this subject up.

Regarding, the benefits, I think it will also make the review work easier (no need to filter by commit) to review. As many migration are trivial, sometimes a simple code review (+ possible test runboat) are enough.

Regarding the possible drawback : here is a use case :
- in October 2022, we create a branch 16, based on 15 with a module module_x present in V15 branch.
- In Octobre 2023, we create a branch 17, based on the 16 (but he module_x has not been ported in v16, or the PR has not been merged), so the V15 base code is copied in v17.
- Then the module is ported in v16.
- In Octobre 2024, we create a branch 18, based on the 17 (but he module_x has not been ported in v17, or the PR has not been merged), so the V15 base code is copied in v18.
- Then the module is ported in v17
Finally, we have a branch 18, with 15 code while newer versions of the module exist.
The risk is that when someone wants to port the module to V18, they will base it on the V15 code, not 17.

That will occures, but I can leave with it. Maybe improving bot could be possible.
Something like : on PR "[MIG] V18 module_x" send a message :
"Thanks for porting this module, it seems you didn't cherry picked the following commits : ......"

So a global +1.

1 proposal :  Regarding the process to remove modules that have not been migrated for several versions :
- I think it should be a yearly work. What about to decide to say that PSC, during each odoo / Oca Days spend a time to remove obsolete modules. I mean, in the next Odoo Experience, the next Release will be presented by Odoo SA and so, new features are making some OCA modules obsoletes. so having a workshop to delete the modules in V16 branch that have been just copied is a good way to avoid having dead pending modules.
- In the mean time, we could decide that when creating the branch v20, we get code from v19 branch, with module from 16 + 17 + 18 + 19 dropping module with a older revision.

1 suggestion : (that will make maybe the first initialization more complex).
we observe in the OCA a better adhesion for the even versions. (the question is not if it is good or not, but it is a reality...). Today, there are 1870 modules in version 14 and 545 in version 15.
If we create in October a branch 16 based on version 15, we will recover only 1/3 of the recent modules. So in two thirds of the cases, we will have to make cherry pick, and the advantage of what you propose will be slight in a first time.
I would therefore propose to initialize the branch 16 with the modules of version 15 + the modules of version 14 which are not present in version 15.
I don't know exactly how this is possible, but I think it's feasible.

Note: this operation would be done only once for V16. For v17, we would have a copy of 16, which would contain modules 14, 15, and 16.

Ref : link (you should be logged.)

image.png




Sylvain LE GAL - Twitter
GRAP - Service informatique (Groupement Régional Alimentaire de Proximité)
Site Web | FramaSphere | Facebook
3 Grande rue des Feuillants, 69001 Lyon
Standard : (+33) 09.72.32.33.17
Service Informatique : (+33) 09.73.79.64.40
Astreinte Informatique : (+33) 06.81.85.61.43
Member of the OCA (Odoo Community Association)


Le mer. 20 juil. 2022 à 14:07, Jesús Alan Ramos Rodríguez <notifications@odoo-community.org> a écrit :
+1

El mié, 20 de jul. de 2022 6:57 a. m., Maxime Chambreuil <notifications@odoo-community.org> escribió:
+1

El mié, 20 de jul. de 2022 06:07, Roussel, Denis <notifications@odoo-community.org> escribió:
As I'm in favor of that change for so long, you definitely convinced me with the arguments you exposed.

So, +1 

On Wed, Jul 20, 2022 at 12:46 PM Stéphane Bidoul <notifications@odoo-community.org> wrote:
Dear contributors,

I'm starting to think about the process to create the 16.0 branches. And the more I think about it, the more I'm convinced we should do it by adding "installable": False in the module manifests, instead of creating empty branches.

This would have several benefits:
  • Improve security. Indeed, currently migration PRs have a lot of commits and reviewers only look at the last 2 commits. By accident or malice, it would be easy for a contributor to sneak bad code in older commits, that would go unnoticed. As the community grows, I think this a very important topic.
  • Avoid CLA bot issues: currently, the CLA bot is flagging old commits that were ok at the time they were created, but may not be valid today as contributors may have changed email, or revoked their CLA.
  • Reduce oca-github-bot complexity: work has to be done to make the bot aware of other branches in migration PRs (notably to look-up maintainers). This would be unnecessary if a migration PR is a normal PR to an existing addon directory. On the contrary, the bot could even detect migration PRs automatically by noticing the change to the installable flag, so this could simplify some processes.
  • Slow git repo growth: by avoiding the recreation of identical commits in several branches we would slow down the git repo size increase.
About the possible drawbacks, I am under the impression that all the reasons we had back then to create empty branches have faded away:
  • Today, Odoo and all the OCA tooling work perfectly well when there are addons marked as uninstallable. They are correctly ignored by linters, tests, and Odoo does not attempt to import the code.
  • Regarding discoverability, the addons table in the README shows a clear view of what is not migrated.
The migration procedure and tools should continue to work as today, to pick up commits that would have been added after branching (basically the git-am process would simply work as it does today)

All we'd need maybe is to agree on a process to remove modules that have not been migrated for several versions. But in a first approach, regular PRs to remove now useless modules would probably be sufficient.

Are there any other arguments (pro or con) that I would have missed ?

Looking forward to reading your feedback on this proposal.

-Stéphane

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe



--

Denis Roussel
Software Engineer
T    : +32 2 888 31 49
M : +32 472 22 00 57


Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
Zone industrielle 22 | L-8287 Kehlen | Luxembourg

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference