Contributors mailing list archives

Browse archives


Re: New module l10n_vn_account_parent depending on non-oca repository

Komit Consulting, Jean-Charles Drubay
- 30/05/2017 12:38:37
Dear Pedro, thanks for your answer.

If my understanding is correct, this leaves me with 2 options:
  • [1] I ask the author to transfer ownership to OCA, then I can fork and make the module compliant with OCA coding guidelines and then we can do a merge to account_financial_tools
  • [2] I create a new module with the same features but without re-using existing code so I respect authorship, then I create a merge request a merge request to account_financial_tools
What do you think?

And do you think such module can make his way to account_financial_tools?

Thank you,


Jean-Charles Drubay
Managing Director
Mobile: +84 (0) 909 64 34 69 | Office: +84 (0)8 35 19 20 73 / Skype: jc.drubay
Address: 2nd Floor, n° 8 street 66, Thao Dien, District 2, Ho Chi Minh City, Vietnam

On Tue, May 30, 2017 at 3:38 PM, Pedro M. Baeza (Tecnativa) <> wrote:
OCA modules shouldn't depend on non OCA modules, because you can't test them and be sure that they are going to continue the same way.


2017-05-25 8:23 GMT+02:00 Jean-Charles Drubay <>:
Dear Contributors,

The freshly launched Vietnam Community is considering creating a module "l10n_vn_account_parent" re-using a module which is not an OCA module:

l10n_vn_account_parent would only create data for view accounts.

"account_parent" is an LGPL license, so I guess it is fine.

However, a dependence to an non OCA module might create some issues with runbot. Maybe adding the url to the external repository in the oca_dependencies.txt file would be enough.

Any early warning or advice would be welcome.


ps: link to the related github discussion


Post to:

Post to: