openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello Joël and others,


I have some concerns about localizations in the OCA. Basically localization
is an endless work and a moving target as laws changes and as Odoo and core
dependencies evolve in new versions.

In this moving target context, I believe only a small subset of
localization work deserve OCA consolidation.

Why?

Because many components of Odoo localizations currently badly fit OCA, for
the following reasons:


   - code quality can easily be too low. Honestly, the two first years
   somebody is working on Odoo, it's quite hard he would produce OCA level
   quality code. Does it mean his work is useless? Nope, it means several
   iterations, customer implementations, Odoo releases etc will be required
   before it finally reach OCA quality.
   - it can easily overlap existing work, just because the guy didn't know
   about the existing work when he started or because the shape of the
   existing work wasn't good enough for him and he had not budget to wait for
   a refactor within the scope of customer project.
   - often the work on some module is 95% the work of a single company or
   single developer. Of course, popular modules tend to get contributions, but
   it often happens than in tough emerging economical contexts, only few
   developers manage to focus on some module. In that case I don't see any
   benefit of putting the code in a team of people who are clueless to help.
   - Companies producing AGPL open source aren't selling licenses. So
   basically what they hope in exchange of their investments is visibility,
   say like paying a partnership but cutting the cruft. By moving a module out
   of a company team to a shared repo like OCA, the visibility is shadowed
   somewhat. So of course, sometimes the benefit of aggressive collaboration
   outweight the image loss. But that's not true when a module is made say 95%
   by a single developer or company for whatever good reason (if it's not a
   good reason, forks just happen).
   - Often the authors of a given module aren't OCA reviewers themselves.
   So what do we do? Are them promoted as reviewers without passing the
   quality approvals? Wouldn't OCA loose its quality commitment if we do so?


So I advocate for a self-moderation of OCA ambitions with localization. I
think OCA should focus on what works currently (all the fantastic
extra-addons mutualization we did during 2013-2014 and OCB).

But IMHO we shouldn't loose the focus by trying to be holistic.

Good open source is well tested and self organizing.
Ruby on Rails, one of the prominent Github project has thousands of
extensions gems. Most of them have continuous integration on Travis CI, a
good coverage and many of them are trustable.
BUT despite this tremendous success, there is no hollistic organization
trying to control all Rails extensions gems ever produced and put them in a
single team.
This is not needed and this would even be bad.

A good gem gets popular and tested. If it's not good, it's forked into
something better.
If company X or developer Y is authoring some gem, it stays under company X
or developer Y Github account.
Only if authorship is really a shared work then a common account is used.
But generally, this is not even required as modules are made modular enough
so that contrib of company X / developer Y can fit in a well tested
extension module if it's not a minor patch.
And this just works, visibility gives great incentives to community heroes
and it just works, possible much better than Odoo ecoystem if you ask
professionals working in these eco-systems.


So, please let's consider these self organizing properties. Let's ensure we
have an excellent "building locks" in the ecosystem by having a great core
and decent APIs, the rest will follow automatically as it does in many
other projects.

So I advocate that OCA offers a common place to consolidate the core of
localizations as a start, but don't claim to be holistic and paralyze the
economics and self organizing properties of the eco-system.

As OCA will succeed with the core, it will be always time to consolidate
more and more modules in that core. But please no premature consolidation
of POC or temporary modules, we have much more interesting and urging stuff
to collaborate on.

So please consider putting localization cores under OCA umbrella, but claim
to embrace all localization modules.


Now I would just say "kudoo" for the work!


Regards.

-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 3942-2434
www.akretion.com




On Mon, Jun 30, 2014 at 11:24 AM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> wrote:

> Hi all,
>
>
> Thanks for bringing your help here. I just have a doubt on localization
> name.
>
> I rather prefer to keep the name of the "locale-country" instead of
> "l10n-country_iso_code". My arguments for that is :
>
>  * Those repository belong to the local community (Spain, France, and so
> on..)
>
>  * They may contain other modules that are not "l10n_like"
>
>  * The country name is easy to remember and search for
>
> So, to summarize, my opinion is that it's better to have the name of the
> country as it represent the work of the whole locale community and not
> "only" the l10n_* modules.
>
> Do you agree here ?
>
>
> Best regards,
>
> Joël
>
>
>
>
>
>
>
>
> On Mon, Jun 30, 2014 at 3:25 PM, Nhomar Hernández <nhomar@xxxxxxxxx>
> wrote:
>
>>
>> 2014-06-30 8:55 GMT-04:30 Nhomar Hernández <nhomar@xxxxxxxxx>:
>>
>> Thanks for the fork you are doing dudes.
>>>
>>
>> jajjaaja I mean "Thanks for the 'job'" ;-)
>>
>>
>>
>> --
>> --------------------
>> Saludos Cordiales
>>
>> Nhomar G. Hernandez M.
>> +58-414-4110269
>> Skype: nhomar00
>> Web-Blog: http://geronimo.com.ve
>> Servicios IT: http://vauxoo.com
>> Linux-Counter: 467724
>> Correos:
>> nhomar@xxxxxxxxxxxxxx
>> nhomar@xxxxxxxxxx
>> twitter @nhomar
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~openerp-community
>> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openerp-community
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
>
>
> *camptocamp*
> INNOVATIVE SOLUTIONS
> BY OPEN SOURCE EXPERTS
>
> *Joël Grand-Guillaume*
> Division Manager
> Business Solutions
>
> +41 21 619 10 28
> www.camptocamp.com
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>