Archives
Contributors
Re: Procedure to create 16.0 branches
Hi,
I'm no techie, and don't pretend to deeply understand this stuff. Also not a PSC of any repo. I am not very personally affected by whatever decision is made here and will happily defer to any decision.
Regards benefits of this approach, the first question I ask is can this be achieved in other ways. Usually people tell me it is impossible immediately. I won't argue back, just random thoughts.
- Improve security. One thought regards nefarious commits injected into migration. Is this solvable in other ways? Something like an AST/semantic diff maybe or even just a regular diff against last release. In fact a regular diff against last release may identify missed commits too. But anyway some kind of semantic diff outside of migration may be useful too as it would just ignore format changes. However, I think security is a separate important topic that needs a wider discussion regardless of whatever outcomes here are and we should be vigilant to those risks. But also as a reviewer, I think I'd rather review a semantic diff anyway.
- Avoid CLA bot issues: Do we really need to preserve ALL history every release - what about a squash merge - that maintains all the prior authors? Then maybe we can get an excpetion for that case in bot. For that 1 time ever you need a blame on a file 6 years ago, you can still traceback through versions.
- Reduce oca-github-bot complexity: I actually thought that work was done already. But in any case, is the argument here valid? Because not all modules in prior repo(s) would be merged at time the new one is created. So don't you avoid the complexity, until you don't? Wouldn't we need the functionality regardless? I don't know, genuine question.
- Slow git repo growth: As above for CLA Bot.
My general feeling I am getting -
- Maintainers with tightly controlled, homogenous repos with a small number of maintainers and modules are in favour. These also tend to be "additive" repos, i.e. it is new functionality with not a lot of integration points. They also tend to be a bit more "technical". There is a very high likelihood of migration and also fairly rapidly. However, the contributors on those repos are more than capable of a 5 minute dance to do the port work.
- PSC's with large heterogeneous repos with many modules and contributors aren't so much in favour. Of course in these repos there tends to be a LOT of flux from version to version. Place like product-attribute, sale-workflow. These are often "insertive" type modules, putting themselves in middle of business processes. Design changes, upstream functionality changes, lots of modules dropping, reappearing.
I know for myself and some modules I have some involvement with.
office 365 auth - hasn't changed between versions for 7 years. I don't even have any clients paying for it anymore - but 1 guy emails me once a year asking me to bump version number because it still works.
partner statements - we did a big refactor for 11 or 12.0 maybe, a few minor changes for 13.0 accounting but less than you'd think because it is fundamentally just adding a couple reports.
Now when I'm doing/reviewing those, I'll admit it does seem a bit wasteful this whole dance but it is no big deal.
operating-unit - literally just a bunch of modules sticking a single field on a model, these are often awful to migrate because that happens in the middle of all sorts of functions, lots of interdependencies, stupid broken Odoo record rules. Plus they look easy, so often people seem to pick them for their first ever migration, review sucks on these and we get quite a few unexpected oversights. You really do need to download and test these PR's.
I know it should make no difference, but my head just thinks better starting clean.
sale-workflow/product-attribute type repos - honestly, a lot of the time in these repos it is about merging modules, deprecating modules, combining functionality, finding better repos as focus changes. I'm probably wrong, but I feel like prepopulating uninstallable is probably more work and missed opportunities.
Anyway just my thoughts.
But also, even if it is OK for 16, what about odd number version :) (This is a joke).
On Thu, Jul 21, 2022 at 10:42 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
> To make sure people reason about the correct arguments, let me emphasize again that the migration process would be strictly identical.Although theoretically you can use the same commands (but I repeat, I remember some problems in the past with this - I will try to dig on the history to find any -), what will happen for sure is that people forget to do/don't know such initial steps and appear that the migration pull request is correct, while it doesn't contain the missing commits, charging on the reviews to check this, so that's the real issue, together with other strong arguments like the IDE search, cleaning, etc.And I also agree having some repositories with one approach and another with the other approach is a mess. You have done the installable=False approach in the past for your specific repositories (mis-builder, storage, product-pim and queue mostly), because you do the migration yourself, not involving other contributors, but the rest of the repositories can't apply this method.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 03:15 - 21 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.