Archives
Contributors
Re: Procedure to create 16.0 branches
Hi, great idea Stéphane.
Remember that there are modules that change their name from version to version, so the bot could understand that a module is not migrated when in fact it is.
An example would be account_menu, deprecated in favor of account_usability. The functionality is included in account_usability, so we do not need to migrate account_menu to 16.0.
WDYT?
On the other hand, I want to make a comment about "(...)I take good note of the idea of automatically picking up unmigrated modules from 14.0 in 16.0. (...)"
Remember that there are modules that change their name from version to version, so the bot could understand that a module is not migrated when in fact it is.
An example would be account_menu, deprecated in favor of account_usability. The functionality is included in account_usability, so we do not need to migrate account_menu to 16.0.
WDYT?
El mié, 20 jul 2022 a las 16:32, Simone Orsi (<notifications@odoo-community.org>) escribió:
+100 for this approach.Regarding automatic porting: would be nice but due to the fact that we'll probably have tons of PRs I'd avoid spending time on such a tool since we already have too many PRs to shepherd.I'm pretty sure the tool drafted here (which will land soon into OCA/oca-port) will help a lot with porting (especially if we start integrating in the branches the blacklist of PRs and commits to not port, eg: https://github.com/OCA/edi/pull/513).Thank you Stéphane for the proposal, thanks everybody for the feedback :)On Wed, Jul 20, 2022 at 4:17 PM Stéphane Bidoul <notifications@odoo-community.org> wrote:On Wed, Jul 20, 2022 at 3:52 PM Sylvain LE GAL <notifications@odoo-community.org> wrote: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.Unfortunately this idea of a porting bot for OCA is kind of stuck because only PSC members would be able to modify branches created by the bot.There is an open issue about this: https://github.com/OCA/oca-github-bot/issues/55. If there are new ideas about this, there is the place to discuss them :)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.I personally use this little script to facilitate porting pull requests across branches. A much more sophisticated one is in development here.But in the end, these porting problems already exist today, and will not really be different if we create new branches by marking addons installable=False.So the main thing to do IMO is put a prominent message in the migration procedure wiki to explain how to identify and port missing commits from previous branches.I take good note of the idea of automatically picking up unmigrated modules from 14.0 in 16.0. No promise, I'll see what I can do. Contributions in maintainer-tools are always welcome :)Best,-sbi_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Simone OrsiFull stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
| ||||||||||||||||||
|
by Harald Panten Lopez - 04:46 - 20 Jul 2022
Reference
-
Procedure to create 16.0 branches
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.
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
by Stéphane Bidoul - 12:45 - 20 Jul 2022 - 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.