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
Coop IT Easy SC agréée, Carmen Bianca Bakker
- 20/07/2022 15:02:23 
+1, history integrity is important.

Le mercredi 20 juillet 2022 à 10:46 +0000, Stéphane Bidoul a écrit :

> 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

Reference