Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • Re: Procedure to create 16.0 branches
    On 20-07-2022 20:47, Lois Rilo Antelo wrote:

    Therefore, I like the idea proposed by Holger, I think the branch initialization mode can be have 2 options being the current mode the default, the new mode for sure can work for specific repos with very defined scope and clear and active PSC like mis-builder (I could even give it a try in ddmrp).

    I like this too. Can we give it a try by making this opt-in for 16.0 and reevaluate for 17.0?

    Regards,
    Stefan

    by Stefan Rijnhart - 10:35 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    > commits SHA are equal with proposed one

    It will be if the module or the changes are already in the branch when creating the 16.0 branch, but my statement was for the missing commits (a module not present when the branch was created or new features introduce after that). Moreover, cloning 16.0 with --single-branch with the current approach will be tons lighter than with the one you want to put.

    Regards.
    by Pedro M. Baeza - 08:51 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Hi,

    From my point of view, a change that would need more PSC dedication to make it work is not a good idea. With this proposal, that's what it looks like to me, PSCs would need to do these tasks that are not needed now:

    - Review obsolete/discontinued modules modules and create a PR to remove them.
    - Pay attention to missing commits on migration PRs. It is true that this can happen now if a migration PR is open for a long period (while the PR is open new changes can be merged in previous versions), but the chances are lower and almost zero at the moment of opening the PR (zero if the contributor fetches just before starting to migrate).
    - Attend more CI issues on forward ports as they will be more frequent. I would say that currently a bot that forward ports stuff is a "nice to have" but with this proposal it would be a "must have".

    On top of this, in point one I think it is not an easy task either. Think about the following scenario: module A is in branch 16.0 of repo R but not migrated yet, 1 year goes by and therefore the PSC proceeds to remove module A. Then a couple of months later someone finally migrates module A to version 16, he/she will re-add all commits and code, so 3 big diffs for a single moduleone mor. This highlights a question that has a difficult answer for me: How long does it take for a module to be obsolete and be removed?

    From the perspective of a contributor/developer, there is also a problem that annoyed me a lot when branches were created with installable false, and it was that you will find stuff that is not relevant when searching things in your IDE as the non-migrated code is there. I think it is worth thinking about this as it will affect the day-to-day work of frequent contributors. 

    Also, when looking at repositories browsing github it is now very quick and easy to see what is dead, what is not migrated to the latest version, etc. you just need to see if there is something in a given branch in a given repository. It is true that the README of the repo can help, but be honest... I never scroll down to see the README, I don't think many people would do that intuitively.

    I think the proposed approach can work for a number of repos, but not for the majority:
    - imagine sale-workflow without the natural cleaning of the clean start each year.
    - imagine a repository that gets contributions in v15 and then never again in next versions, the modules will be copied during years to newer versions.

    Obviously these things can be mitigated but I think now modules and repositories "die" more naturally.

    Therefore, I like the idea proposed by Holger, I think the branch initialization mode can be have 2 options being the current mode the default, the new mode for sure can work for specific repos with very defined scope and clear and active PSC like mis-builder (I could even give it a try in ddmrp).

    My 2 cents :)

    Kind regards, 


    On Wed, Jul 20, 2022 at 8:42 PM Roussel, Denis <notifications@odoo-community.org> wrote:
    To summarize:

    • commits SHA are different with current behaviour
    • commits SHA are equal with proposed one
    Moreover, for your size problem, current behaviour is taking more place than proposed one as new main branches are sharing same commits with preceding one.

    You can test it locally (I did it) with git rev-list --disk-usage --objects --all

    So, that point is solved.


    On Wed, Jul 20, 2022 at 7:57 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
    Dennis, the images unfortunately are not shown (Odoo/OCA instance bug), but the point in `This will increase the size of the repository the same, as no common ancestor and then different SHA.` is that it will affect the same on size on one procedure or the other.

    > I see advantages here as currently if a module is not there, that does not mean if it is migrated yet or has been deprecated. With proposed approach, you can detect it more easily (present in previous branch, not in current. Moreover in the commit history you can see why it has been deprecated and learn about changes you maybe missed).

    I don't get your point here, but it's the same good or bad, as it depends when a possible new module has arrived on prior branches.

    > From several same approach repositories knowledge, I would say this will lead to a cleaner situation and an easier newcomers contribution processes understanding.

    I have already expressed why it won't be cleaner and the problem not only for newcomers, but for existing contributors or reviewers.

    Regards.

    _______________________________________________
    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



    --
    Lois Rilo Antelo
    Odoo consultant at ForgeFlow S.L.
    by Lois Rilo Antelo - 08:46 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    To summarize:

    • commits SHA are different with current behaviour
    • commits SHA are equal with proposed one
    Moreover, for your size problem, current behaviour is taking more place than proposed one as new main branches are sharing same commits with preceding one.

    You can test it locally (I did it) with git rev-list --disk-usage --objects --all

    So, that point is solved.


    On Wed, Jul 20, 2022 at 7:57 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
    Dennis, the images unfortunately are not shown (Odoo/OCA instance bug), but the point in `This will increase the size of the repository the same, as no common ancestor and then different SHA.` is that it will affect the same on size on one procedure or the other.

    > I see advantages here as currently if a module is not there, that does not mean if it is migrated yet or has been deprecated. With proposed approach, you can detect it more easily (present in previous branch, not in current. Moreover in the commit history you can see why it has been deprecated and learn about changes you maybe missed).

    I don't get your point here, but it's the same good or bad, as it depends when a possible new module has arrived on prior branches.

    > From several same approach repositories knowledge, I would say this will lead to a cleaner situation and an easier newcomers contribution processes understanding.

    I have already expressed why it won't be cleaner and the problem not only for newcomers, but for existing contributors or reviewers.

    Regards.

    _______________________________________________
    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
    by Denis Roussel - 08:40 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Dennis, the images unfortunately are not shown (Odoo/OCA instance bug), but the point in `This will increase the size of the repository the same, as no common ancestor and then different SHA.` is that it will affect the same on size on one procedure or the other.

    > I see advantages here as currently if a module is not there, that does not mean if it is migrated yet or has been deprecated. With proposed approach, you can detect it more easily (present in previous branch, not in current. Moreover in the commit history you can see why it has been deprecated and learn about changes you maybe missed).

    I don't get your point here, but it's the same good or bad, as it depends when a possible new module has arrived on prior branches.

    > From several same approach repositories knowledge, I would say this will lead to a cleaner situation and an easier newcomers contribution processes understanding.

    I have already expressed why it won't be cleaner and the problem not only for newcomers, but for existing contributors or reviewers.

    Regards.
    by Pedro M. Baeza - 07:56 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Hi Pedro,
    • This will increase the size of the repository the same, as no common ancestor and then different SHA.
    You're wrong on this as this is the case currently (different SHA). Example with stock_cycle_count module:


    image.png


    image.png

    When basing the new main branch on preceding one:


    image.png


    image.png

    • Derived from this, it requires that the reviewers alw ays need to check if the migration pull request contains the latest commits.
    That's already the case depending on how long the migration takes and if reviewers detect the missing ones or not.

    • It will generate extra burden for deprecated modules, requiring to make a pull request to remove them,
    I see advantages here as currently if a module is not there, that does not mean if it is migrated yet or has been deprecated. With proposed approach, you can detect it more easily (present in previous branch, not in current. Moreover in the commit history you can see why it has been deprecated and learn about changes you maybe missed).

    • In the past, having uninstallable modules has cost a lot of problems. Remember the static folder problem that loads the Python files, the switch from version 2 to 3. Now they are not present, but nothing prevents a new side effect from happening in the future. Better to have the house cleaned.
    Predicting behaviour on possible things is not an argument IMHO. With pre-commit, I think we can manage most of things that can happen (e.g.: generating a clean setup folder, ...).


    IMHO the situation in the early years of OCA is not the same as the one we know now. Context and tools have changed.

    From several same approach repositories knowledge, I would say this will lead to a cleaner situation and an easier newcomers contribution processes understanding.


    On Wed, Jul 20, 2022 at 4:52 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
    Returning back to this approach is a mistake IMO, as it has more cons than pros. First of all, one of the advantages that you mention is not correct, or at least, depending from the perspective, that is the "slow git repo growth": if you download a single new branch, it will cost a lot more, as it has all the commit history from all the modules. This gets even worse when the modules are deprecated (more on this later).

    And about the drawbacks, there are still bad interactions with modules with previous versions code due to Python or ORM peculiarities (check for example this PR for fixing a code that shouldn't be executed not being the module installed), and for sure more will appear. Going to the process of discovering these problems and fixing this is an unneeded maintenance burden. The discoverability will have the same problem, as people don't get used to having useless folders an d to need to go to that file to check it or open the manifest. Even more, I think the OCA apps store module will have problems with this approach (but that's only suspicions).

    Now let me summarize again the rest of the cons that were the reason to change to this approach:
    • When the branches are created for the new 16.0 version, activity in the prior branch 15.0 may happen until the migration of the module is done, but the 16.0 branch won't reflect these new commits. There's a high risk of the contributors of the migration not including latest changes, or to work on the deprecated source code and come to OCA with their pull request to be discouraged by one qualified reviewer saying that they need to rework the migration including the missing commits. Forcing and teaching people to use tools like oca-port is a high entry barrier. Someone has proposed to develop a bot for automatically doing these forward-ports, but it will have lots of problems as well:
      • First of all, it needs to be developed, which is not an easy task and needs to be done. Adding extra tools for something that is not needed with another approach is not the convenient way to go.
      • If there's already a migration PR proposed, the new commits won't be there, and it will require a rebase by the migrator (again more contribution friction).
      • Those extra commits will lose the security signing that may be present in previous branches. The only way to not lose them is that the same author makes the commit signing it in the new branch.
      • There can potentially be the same CLA problems.
      • When the bot does the forward-ports, CIs may be red due to external reasons, but then these commits won't never reach the new branch unless manual actions are done.
      • This will increase the size of the repository the same, as no common ancestor and then different SHA.
    • Derived from this, it requires that the reviewers alw ays need to check if the migration pull request contains the latest commits. With the previous approach, there are less chances that they are not included, and we light up the reviewing process.
    • Also derived from the first point, it's the lack of homogeneity in the processes. With the current one, everything follows the same procedure. This is VERY IMPORTANT: to have only one way of doing everything, not having to know different processes depending on the state of the branch.
    • It will generate extra burden for deprecated modules, requiring to make a pull request to remove them, and creating a very big diff commit of such removal, increasing the branch and repository size (remember that there will be at least one commit adding the module, and another removing it, so double diff).
    • Modules being migrated with a jump of version will have the same problem of not having any of the commit history.
    • Rebel modules configuration and similar CI tricks may cause problems on new branches.
    • In the past, having uninstallable modules has cost a lot of problems. Remember the static folder problem that loads the Python files, the switch from version 2 to 3. Now they are not present, but nothing prevents a new side effect from happening in the future. Better to have the house cleaned.
    The fact that some of you are using this approach in some repositories is not representative, as that repositories have a very limited scope (few modules), and very controlled by few contributors, but try it in OCA/sale-workflow or OCA/purchase-workflow...

    Please reconsider your approach. If not, we at Tecnativa don't know if we can afford this process in our contributions to OCA.

    Regards.

    _______________________________________________
    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
    by Denis Roussel - 07:46 - 20 Jul 2022

    4 attachments 4 attachments

    image.png
    image.png
    image.png
    image.png
  • Re: Procedure to create 16.0 branches
    +1

    Le mer. 20 juil. 2022, 00:46, Stéphane Bidoul <notifications@odoo-community.org> 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

    by Cyril VINH-TUNG - 06:51 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches 
    I'm mostly with Pedro here, a lot of the peculiarities of Odoo and the OCA 
setup as it is at the moment, make the current approach (=start with a clean 
slate for every version) more convenient for heavily fragmented repo's. Think 
web, server-tools. 

On the other hand I get that for "fully owned" (I just made that up) repos 
like the ones 	Stéphane is busy with (I assume), the other approach is more 
convenient. Can't we have it both ways, default is what we do now and PSC's 
are free to switch to Stéphane's model? That should get a different name then 
probably and also probably needs some support in MQT.
It will be good for any scenario to have some kind of automated migration in 
the bot, so I think we could have a look at that and if/what MQT needs during 
the code sprint for making both approaches coexist?


-- 
Your partner for the hard Odoo problems
https://hunki-enterprises.com
    by Holger Brunn - 06:00 - 20 Jul 2022

    1 attachments 1 attachments

    signature.asc
  • Re: Procedure to create 16.0 branches
    >> Also derived from the first point, it's the lack of homogeneity in the processes. With the current one, everything follows the same procedure. This is VERY IMPORTANT: to have only one way of doing everything, not having to know different processes depending on the state of the branch.
    > Please note that the current procedure with "git format-patch | git am" will continue to work as before: it will just pick up missing commits. There is no obligation to learn new tools.

    I don't remember the details right now, as the other procedure has been absent for a long time, but using such instructions generates conflicts on several occasions. Trust me, I suffered from them in my OCA beginnings...

    >> Modules being migrated with a jump of version will have the same problem of not having any of the commit history.
    > That is true but this will fade away over time.

    Why will it fade away? A new module can be introduced in any version, so this will always happen.

    >> Rebel modules configuration and similar CI tricks may cause problems on new branches.
    > All the CI is now configured with copier questions, and we will reset the rebel module groups when creating new branches. So that should not be a problem.

    I have put an example, but there are several other things that will conflict, like packages, environment variables, etc.

    And you are missing very important points, like the one about the trust of a new migration PR if it contains missing commits or not. When a contributor adds a pull request and it only contains the migration commit, is it because there's no missing commits in the prior branch, or is it because he/she has missed them as the natural tendency for a newcomer is to just change installable to True and test if it works, and then commit the changes? This transfers a lot of responsibility to the reviewers to check this. With the current approach, it's very easy to detect an incorrect migration PR.

    Note that the problem about missing commits is very common, as the migration of the modules happens a lot of time after the new version is released, as people need to incorporate the new version in their flows.

    But the main important thing is that I don't see any clear exposed advantages to change the approach. The ones you have mentiones:

    > 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.

    The same security problem with missing commits.

    > 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.

    The same CLA bot issues with missing commits.

    > 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.

    Such things have already been developed (thanks Sylvain!), so this is not a problem anymore.

    > Slow git repo growth: by avoiding the recreation of identical commits in several branches we would slow down the git repo size increase.

    As said, this is not true depending on your git usage (single branch clone), or with the deprecated modules (double diff, adding and removing stuff).

    Regards.
    by Pedro M. Baeza - 05:56 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Pedro,

    Let me answer what I perceive has the most important points:

    > Also derived from the first point, it's the lack of homogeneity in the processes. With the current one, everything follows the same procedure. This is VERY IMPORTANT: to have only one way of doing everything, not having to know different processes depending on the state of the branch.

    Please note that the current procedure with "git format-patch | git am" will continue to work as before: it will just pick up missing commits. There is no obligation to learn new tools.

    > Modules being migrated with a jump of version will have the same problem of not having any of the commit history.

    That is true but this will fade away over time.

    > Rebel modules configuration and similar CI tricks may cause problems on new branches.

    All the CI is now configured with copier questions, and we will reset the rebel module groups when creating new branches. So that should not be a problem.

    -sbi


    On Wed, Jul 20, 2022 at 4:52 PM Pedro M. Baeza (Tecnativa) <notifications@odoo-community.org> wrote:
    Returning back to this approach is a mistake IMO, as it has more cons than pros. First of all, one of the advantages that you mention is not correct, or at least, depending from the perspective, that is the "slow git repo growth": if you download a single new branch, it will cost a lot more, as it has all the commit history from all the modules. This gets even worse when the modules are deprecated (more on this later).

    And about the drawbacks, there are still bad interactions with modules with previous versions code due to Python or ORM peculiarities (check for example this PR for fixing a code that shouldn't be executed not being the module installed), and for sure more will appear. Going to the process of discovering these problems and fixing this is an unneeded maintenance burden. The discoverability will have the same problem, as people don't get used to having useless folders an d to need to go to that file to check it or open the manifest. Even more, I think the OCA apps store module will have problems with this approach (but that's only suspicions).

    Now let me summarize again the rest of the cons that were the reason to change to this approach:
    • When the branches are created for the new 16.0 version, activity in the prior branch 15.0 may happen until the migration of the module is done, but the 16.0 branch won't reflect these new commits. There's a high risk of the contributors of the migration not including latest changes, or to work on the deprecated source code and come to OCA with their pull request to be discouraged by one qualified reviewer saying that they need to rework the migration including the missing commits. Forcing and teaching people to use tools like oca-port is a high entry barrier. Someone has proposed to develop a bot for automatically doing these forward-ports, but it will have lots of problems as well:
      • First of all, it needs to be developed, which is not an easy task and needs to be done. Adding extra tools for something that is not needed with another approach is not the convenient way to go.
      • If there's already a migration PR proposed, the new commits won't be there, and it will require a rebase by the migrator (again more contribution friction).
      • Those extra commits will lose the security signing that may be present in previous branches. The only way to not lose them is that the same author makes the commit signing it in the new branch.
      • There can potentially be the same CLA problems.
      • When the bot does the forward-ports, CIs may be red due to external reasons, but then these commits won't never reach the new branch unless manual actions are done.
      • This will increase the size of the repository the same, as no common ancestor and then different SHA.
    • Derived from this, it requires that the reviewers alw ays need to check if the migration pull request contains the latest commits. With the previous approach, there are less chances that they are not included, and we light up the reviewing process.
    • Also derived from the first point, it's the lack of homogeneity in the processes. With the current one, everything follows the same procedure. This is VERY IMPORTANT: to have only one way of doing everything, not having to know different processes depending on the state of the branch.
    • It will generate extra burden for deprecated modules, requiring to make a pull request to remove them, and creating a very big diff commit of such removal, increasing the branch and repository size (remember that there will be at least one commit adding the module, and another removing it, so double diff).
    • Modules being migrated with a jump of version will have the same problem of not having any of the commit history.
    • Rebel modules configuration and similar CI tricks may cause problems on new branches.
    • In the past, having uninstallable modules has cost a lot of problems. Remember the static folder problem that loads the Python files, the switch from version 2 to 3. Now they are not present, but nothing prevents a new side effect from happening in the future. Better to have the house cleaned.
    The fact that some of you are using this approach in some repositories is not representative, as that repositories have a very limited scope (few modules), and very controlled by few contributors, but try it in OCA/sale-workflow or OCA/purchase-workflow...

    Please reconsider your approach. If not, we at Tecnativa don't know if we can afford this process in our contributions to OCA.

    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 Stéphane Bidoul - 05:30 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Since the very first decision of deleting everything I was sure this was the proper cycle and fixing the exceptions when importing incorrect things was the main issue.

    I am super +1 with this.


    El mié, 20 jul 2022 a la(s) 05:46, Stéphane Bidoul (notifications@odoo-community.org) escribió:
    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



    --

    Nhomar G Hernández

    Vauxoo | CEO

    ¡Construyamos algo genial!
    Cel: +52 (477) 393.3942 | Telegram: nhomar | Twitter: @nhomar

    México · Venezuela · Costa Rica · Perú

    phone nhomar@vauxoo.com phone vauxoo.com/contactus  

    by Nhomar Hernández - 05:16 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Returning back to this approach is a mistake IMO, as it has more cons than pros. First of all, one of the advantages that you mention is not correct, or at least, depending from the perspective, that is the "slow git repo growth": if you download a single new branch, it will cost a lot more, as it has all the commit history from all the modules. This gets even worse when the modules are deprecated (more on this later).

    And about the drawbacks, there are still bad interactions with modules with previous versions code due to Python or ORM peculiarities (check for example this PR for fixing a code that shouldn't be executed not being the module installed), and for sure more will appear. Going to the process of discovering these problems and fixing this is an unneeded maintenance burden. The discoverability will have the same problem, as people don't get used to having useless folders and to need to go to that file to check it or open the manifest. Even more, I think the OCA apps store module will have problems with this approach (but that's only suspicions).

    Now let me summarize again the rest of the cons that were the reason to change to this approach:
    • When the branches are created for the new 16.0 version, activity in the prior branch 15.0 may happen until the migration of the module is done, but the 16.0 branch won't reflect these new commits. There's a high risk of the contributors of the migration not including latest changes, or to work on the deprecated source code and come to OCA with their pull request to be discouraged by one qualified reviewer saying that they need to rework the migration including the missing commits. Forcing and teaching people to use tools like oca-port is a high entry barrier. Someone has proposed to develop a bot for automatically doing these forward-ports, but it will have lots of problems as well:
      • First of all, it needs to be developed, which is not an easy task and needs to be done. Adding extra tools for something that is not needed with another approach is not the convenient way to go.
      • If there's already a migration PR proposed, the new commits won't be there, and it will require a rebase by the migrator (again more contribution friction).
      • Those extra commits will lose the security signing that may be present in previous branches. The only way to not lose them is that the same author makes the commit signing it in the new branch.
      • There can potentially be the same CLA problems.
      • When the bot does the forward-ports, CIs may be red due to external reasons, but then these commits won't never reach the new branch unless manual actions are done.
      • This will increase the size of the repository the same, as no common ancestor and then different SHA.
    • Derived from this, it requires that the reviewers always need to check if the migration pull request contains the latest commits. With the previous approach, there are less chances that they are not included, and we light up the reviewing process.
    • Also derived from the first point, it's the lack of homogeneity in the processes. With the current one, everything follows the same procedure. This is VERY IMPORTANT: to have only one way of doing everything, not having to know different processes depending on the state of the branch.
    • It will generate extra burden for deprecated modules, requiring to make a pull request to remove them, and creating a very big diff commit of such removal, increasing the branch and repository size (remember that there will be at least one commit adding the module, and another removing it, so double diff).
    • Modules being migrated with a jump of version will have the same problem of not having any of the commit history.
    • Rebel modules configuration and similar CI tricks may cause problems on new branches.
    • In the past, having uninstallable modules has cost a lot of problems. Remember the static folder problem that loads the Python files, the switch from version 2 to 3. Now they are not present, but nothing prevents a new side effect from happening in the future. Better to have the house cleaned.
    The fact that some of you are using this approach in some repositories is not representative, as that repositories have a very limited scope (few modules), and very controlled by few contributors, but try it in OCA/sale-workflow or OCA/purchase-workflow...

    Please reconsider your approach. If not, we at Tecnativa don't know if we can afford this process in our contributions to OCA.

    Regards.
    by Pedro M. Baeza - 04:51 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Hi, great idea Stéphane.

    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 Orsi

    Full 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



    --


     

    Harald Panten López

    CEO

    Sygel Technology S.L

    		 
    		+34 613 04 76 66
    		harald.panten@sygel.es
    		https://www.sygel.es
    		C/ Àlaba 61, 5ª planta, 08005, Barcelona
     
     
     
    by Harald Panten Lopez - 04:46 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    +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 Orsi

    Full stack Python web developer, Odoo specialist, Odoo Community Board Member, in love with open source.
    by Simone Orsi - 04:30 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    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
    by Stéphane Bidoul - 04:16 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    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

    by Sylvain LE GAL - 03:51 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    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

    by Yann Papouin - 03:40 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    Hello,

    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 <notifications@odoo-community.org> 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 <notifications@odoo-community.org> wrote:
    +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



    --
    Raphaël Valyi
    Founder and consultant

    by "Raphaël Valyi" <rvalyi@akretion.com> - 03:11 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches 
    +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
    by Carmen Bianca Bakker - 03:05 - 20 Jul 2022
  • Re: Procedure to create 16.0 branches
    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

    by Sylvain LE GAL - 03:01 - 20 Jul 2022

    1 attachments 1 attachments

    image.png