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 "Richard deMeester" <richard.demeester@willdooit.com> - 21/07/2022 07:07:03

Having just read through many points, I don't want to throw too much weight behind proposal for or against.

But I will echo some of the points Lois raised.

I too, often search code for bits and pieces using my IDE, and to then some time later realse that slabs of results are from 1 or 2 versions ago and are "uninstallable".

Or seeing things in results and thinking "oh, I thought that approach was now depracated".

Modules which miss a version and get taken up again is an issue I wonder about, too.

And finally, although only small, I often look at the modules list in a repo and would, based on that, assume it is available in that version.


As a small contributor, I look on and wish you the best outcome whichever way it goes.  In house, we blanket start with a clean slate each revision as it encourages rethinking of the approach against what the current practices and architecture demands.

Good luck.

 

 

Kind Regards 

 

 

A close up of a sign Description automatically generated 

 

Richard deMeester 

Senior Development Analyst 

richard.demeester@willdooit.com 

 

 

 

 

T: (03) 9135 1900 | M: 0403 76 76 76 | A: Bld 10/435 Williamstown Road, Port Melbourne, 3207 

 

A picture containing monitor, screen, holding, person Description automatically generated 

 

 
MAKING GROWTH THROUGH TECHNOLOGY EASY 

 
Notice: This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by WilldooIT Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of WilldooIT Pty Ltd  ABN 85 006 073 052 or any of its related entities. 

 

 


From: Lois Rilo Antelo <notifications@odoo-community.org>
Sent: Thursday, 21 July 2022 4:47 AM
To: Contributors <contributors@odoo-community.org>
Subject: 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.

_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe

Reference