1. Mailing Lists
  2. Contributors
  3. Re: Procedure to create 16.0 branches

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: Procedure to create 16.0 branches

Re: Procedure to create 16.0 branches

Avatar

Re: Procedure to create 16.0 branches

by
Raphael Makonnen
- 21/07/2022 11:40:09

Hi All,

I am not in favor of this and most of this has already been said by others, but I want to re-iterate:

1. It is currently easy to see at a glance the state of the branch and which modules have been migrated

2. The current migration process for most modules is relatively easy

3. If it hinders or causes friction for current OCA contributors and causes them to engage less in OCA it shouldn't be done. Period.

4. The most important reason:

Except for the few modules that are widely used most modules are migrated after 1+ years of the Odoo SA version release. Quite a few modules are also migrated after more than 1 Odoo SA version release. I.E. version 12 module skips 13 and is migrated to 14 and then someone else migrates it to 13. This will create chaos.

I am also not in favor of an opt-in option because it's just an additional difference that we (developers and users) have to keep in mind (re: #1) and frankly the purported benefits do not outweigh the headaches it will cause.


Regards,

Mike.

On 21/07/2022 12:12, Aarón Henríquez Quintana wrote:
As a developer I love the way it is now.

  • You know clearly what is migrated, and all the history
  • Easy to track what is being migrated
  • The process is clean, and you get used to it very fast, barely 4 commands in git.
  • I think it is safe also, it is a responsibility of the repo maintainer that approves the PR to look at the code and check everything is correct.

If we apply the proposal:

  • It is way more complex for developers, it open a bunch of possibilities:
    • If it was not in v15 at the time the 16.0 branch was created: in this case we will be doing the current procedure
    • If it was, and there is no improvement, then we will do a "normal" migration with 1 single commit, that's ok
    • if it was, but it was improved, we have to include those improvements as well, the diff is not reduced as well.
  • Deleted modules will create greater diffs.
  • If the module was deleted because no one wanted to use it, but later on someone decides to migrate it, the diff is going to be super huge.
  • It is going to be harder to know what is migrated, and being migrated, and what is not necessary.
I understand the improvements of the change but I think those improvements are now important enough with respect to the drawbacks. 

On Thu, 21 Jul 2022 at 10:02, Rémi CAZENAVE - Le Filament <notifications@odoo-community.org> wrote:

Hi all,

I like better the current method (having only working/tested/maintained modules in each branch) for the following reasons :
- I find it easier to see what is available un a given version, what would still need to be migrated, and also to get an idea of which versions are being actively used (though I guess I could look at READMEs, migration issues and overall statistics to get the same info)
- on each Odoo instance we deploy we download specific branch and having lots of unusable code would increase bandwidth and storage (although mostly text that could be compressed, so probably not dramatic neither)

I agree that the process to migrate a module from one version to another is not really easy (at least the first times), but I understand that it would still probably need to be done in order to make sure you get the latest commits from previous branch. I am afraid that this would often be forgotten if not strictly necessary in migration process, and for sure we do not want to transfer this extra burden of checking for each PR whether based on latest commits or not to reviewers / PSC.

Last, I am not in favour of having 2 different processes that can be applied per repo, since it would increase complexity for understanding why 2 repos are not behaving the same, and we may lose newcomers (but also for people not so much involved in OCA) - although here again I understand from discussions this is already the case for some repos.

My 2 cents...

Best Regards,
Rémi CAZENAVE
SCOP Le Filament

Le July 21, 2022 3:52:02 AM UTC, "Raphaël Valyi" <notifications@odoo-community.org> a écrit :
Hello,

My vote goes to the opt-in option at least unless Pedro get convinced, because going against the will of somebody processing such a large portion of the PRs would be a terrible shot in the feet.

That being said, earlier Pedro raised the concern about the possibility to craft an attack commit inside a missing commit that would be cherry-picked just like with the current way of migrating. But:

On Wed, Jul 20, 2022, 3: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

Denis could you confirm this SHA conservation could make us safe against such crafted attack commits in the middle of the missing commits that one would need to cherry-pick with the new procedure?

This crafted commit attack thing is indeed extremely concerning...

_______________________________________________
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

Reference