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
ForgeFlow, S.L., Lois Rilo Antelo
- 20/07/2022 20:44:40
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.

Reference