Contributors mailing list archives
Re: Procedure to create 16.0 branchesby "Raphaël Valyi" <firstname.lastname@example.org> - 20/07/2022 15:08:42
sounds great. However, something we may need to think about:
considering the rate modules are migrated, when v16 will be out we may have something like:
- 2000 v14 modules
- only 600 v15 modules.
So in fact for most of the modules doing these fork branches won't change anything compared to the way we migrate today...
Furthermore many repositories (specially localizations) skipped v15 entirely and might eventually migrate a few core modules to v15 for the sole purpose to get them on v16 with smaller steps (likely the case for OCA/l10n-brazil). If they occur these migrations will happen lately I guess, like november or december. How do we deal with this? Could we request to cre-create the v16 branch for a repo a bit later than the early version you may create automatically soon?
Regards and thanks for your work.
On Wed, Jul 20, 2022 at 9:47 AM Mignon, Laurent <email@example.com> wrote:
I already apply this policy on the repositories I manage.So +1.On Wed, Jul 20, 2022 at 2:07 PM Jesús Alan Ramos Rodríguez <firstname.lastname@example.org> wrote:+1El mié, 20 de jul. de 2022 6:57 a. m., Maxime Chambreuil <email@example.com> escribió:+1El mié, 20 de jul. de 2022 06:07, Roussel, Denis <firstname.lastname@example.org> escribió:As I'm in favor of that change for so long, you definitely convinced me with the arguments you exposed.So, +1On Wed, Jul 20, 2022 at 12:46 PM Stéphane Bidoul <email@example.com> 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:
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)
- 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.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--