1. Mailing Lists
  2. Contributors
  3. Re: OCA Code sprint: sprint topics

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: OCA Code sprint: sprint topics

Re: OCA Code sprint: sprint topics

Avatar

Re: OCA Code sprint: sprint topics

by
SYLEAM SARL, Sylvain Garancher
- 12/09/2017 09:29:17
If I summarize the reasons :
- Reduce the git repo size : git stores files, not diffs. When we commit a file that already exists in another branch, the total repo size is unchanged.
- It blurs the visibility : I agree on that, my colleagues sometimes ask me why the module is not found by Odoo, and it's simply uninstallable because not migrated. But the readme lists migrated and unmigrated modules... maybe they should read it :)
- Keeping the history : Our migration procedure already keeps history, and we squash translation commits to make it more readable.
- Get people to look earlier versions : Sometimes, a module was added in 8.0 after the 9.0 branch creation, and not everyone will think about that to search for a module that fit his needs, so people should already have to look at all branches when searching for a module. But I agree that is not the case. I don't think this point should be addressed by the git repo contents/format.
- Lighter migration PRs diffs : Github now allows (I don't know if it was the case 2 years ago) to display the diff by selecting a range of commits in the PR. Anyway, I personnaly often review by using "git diff" locally (to display diffs between the 10.0 migration PR and 9.0 branch, of diff between two PRs, etc.).
Images intégrées 1

Cordialement,
--



2017-09-12 8:23 GMT+02:00 Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com>:
The reasons I remember why OCA contributors decided a couple of years ago to keep modules on the branch and just mark them as uninstallable was to make lighter the migration PRs diffs and to reduce git needs. Guewen was one of the supporters of this method. Is there any other reason I forget?

Among these years, common issues with this approach has been:

* People saying that the module is there but doesn't work (they eventually changed their installable status and try).
* Having to rescue commits that arrives later in the n-1 version branch than the n version branch creation with the same git method as if the module wasn't there (which was made very easy any way by Stéphane Bidoul any way - example: https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0#technical-method-to-migrate-a-module-from-90-to-100-branch).

Do you think we need to change the method for 11.0 branch?

Regards.



2017-09-12 4:53 GMT+02:00 Graeme Gellatly <gdgellatly@gmail.com>:

On the more cynical side, to stop unscrupulous 3rd parties pinching module names for app store and/or just porting and claiming as their own.

I thought it was something to do with making the diffs easier to read as well, reduce reviewer workload.  Pretty sure thats why we got rid of the unported directory from v7 -> v8.  But I guess you could do git filter-branch script and get the same effect to port historical commits.  That would keep your history, but that kind of serious gitfu needs some instructions.  Not sure how that works with github PR's though, if you can diff one commit to the previous one easily.  DISCLAIMER: I don't really know how to use git, already proven twice today.

Personally, I think for this particular round of porting, where in very many cases the changes will be quite minimal that it would be a very desirable thing to not have a big green diff to wade through for every module.  How its done, idk.  Would be nice to start with a nice empty branch except a README, travis.yml etc, as sometimes when reviewing I find it nice to see a module in the context of its surrounding modules (e.g. similarity, fit). 

There used to be an argument that if the disinterested observer looked and saw something they couldn't live without, then they might port it and become a contributor.  I don't really buy that argument. 


On Tue, Sep 12, 2017 at 2:08 PM, Eric Caudal <eric.caudal@elico-corp.com> wrote:

Main value is to push forward across version the commit history.

IMO, I dont think this is essential as we could always go back across repos to link history if needed be.

I personally do not like to have a bunch of unported modules in the repo: it blurs the visibility of what is actually available.

--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore)
Odoo Gold Partner // Best Odoo Partner APAC 2014 and 2016
On 09/12/2017 09:08 AM, Dave Lasley wrote:
<blockquote type="cite" cite="mid:F47BABEE-7893-4D22-AB4C-B99F723FF55E@laslabs.com">

Is there a reason that we bring forward non-migrated modules into the new branch anyways? 


IMO the cleanest approach would be to let the modules sit where they are. This would also get people into the habit of looking at the past versions, instead of just taking the current branch at face value.

— Dave Lasley

On Sep 11, 2017, at 5:23 PM, Eric Caudal <eric.caudal@elico-corp.com> wrote:

Agree with Maxime.

The idea is to not overload the repo unnecessary with unlikely-to-be-migrated modules.

Contributors willing to migrate a 8.0 (not LTS) or 9.0 can anytime propose a specific PR.


--
Eric Caudal [Founder and CEO]
Skype: elico.corp. Phone: + 86 186 2136 1670 (Cell), + 86 21 6211 8017/27/37 (Office)
Elico Shanghai (Hong Kong/Shenzhen/Singapore)
Odoo Gold Partner // Best Odoo Partner APAC 2014 and 2016
On 09/11/2017 11:38 PM, Maxime Chambreuil wrote:
<blockquote type="cite" cite="mid:CADkUEL=q-PGESq-6JmUcbgWpuN58XQ-To7R+8W43oxwS9OvaXQ@mail.gmail.com">
I think we agreed in a previous discussion (a long time ago) that only modules migrated to v10 should be in the v11 branches.

Ursa Information Systems Maxime Chambreuil
Project Manager / Consultant

Ursa Information Systems
1450 W Guadalupe Road, Suite 132
Gilbert, Arizona, 85233

Office:     1-855-URSA ERP x 710
                1-855-877 2377 x 710
Mobile:   1-602-427-5632

On Mon, Sep 11, 2017 at 10:23 AM, David Beal <david.beal@akretion.com> wrote:
Thanks Alexandre for this doc

Before migrate to v11 we could define which modules must be remove from source code in v10 ?

example  https://github.com/OCA/stock-logistics-tracking/blob/8.0/README.md
                 https://github.com/OCA/stock-logistics-tracking/blob/10.0/README.md


Don't you think ?


Bonne journée


David BEAL - Akretion
Odoo Development / Integration

2017-09-11 13:08 GMT+02:00 Alexandre Fayolle <alexandre.fayolle@camptocamp.com>:
Hello it's me again,

Right now we have identified a small number of sprint topics for the
code sprint.

* Migration of modules to Odoo 10.0: lots of PR to review / finalize / merge

* starting to migrate modules to Odoo 11.0 : lots of reviews to create

* unification of our CI tools (Travis and Runbot) to share a single code
base: Jairo Llopis, Moisés López, Dave Lasley

* OpenUpgrade for v11

* Weblate platform (Jesús Zapata, Moisés López, Alexandre Fayolle)

* OCA Administrative tooling (Joël Grand-Guillaume): help scripting some
administrative tasks for the OCA (repository creation, invoicing...)

* OCA Distribution (Daniel Reis): bootstrap an OCA Branded Odoo distribution


If you want to propose working on a specific topic and be responsible
for the track, please answer this email, and I will add your track to
the list.

The reference document we will try and keep up to date is at

https://docs.google.com/document/d/19Wgdmnu5SPSHSLUM7gnBLHWdn9gJvAauVhsSBqkpqE4/edit#heading=h.hp5xqq8jbhks

-- 
Alexandre Fayolle
Chef de Projet
Tel : +33 4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

_______________________________________________
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


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



********************************************************************************
Ce message et toutes les pièces jointes (ci-après le "message") sont établis à
l'intention exclusive de ses destinataires et sont confidentiels. Si vous
recevez ce message par erreur, merci de le détruire et d'en avertir
immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa
destination, toute diffusion ou toute publication, totale ou partielle, est
interdite, sauf autorisation expresse. L'internet ne permettant pas d'assurer
l'intégrité de ce message, SYLEAM décline toute responsabilité au titre de ce
message, dans l'hypothèse où il aurait été modifié.

This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender. Any use not in accord with its
purpose, any dissemination or disclosure, either whole or partial, is prohibited
except after formal approval. The internet can not guarantee the integrity of
this message. SYLEAM cannot therefore be liable for the message if modified.
********************************************************************************

Reference