← Back to team overview

openerp-community team mailing list archive

Re: Maintainers needed for aeroo reports in OCA


Dear All,

I support Alexandre's vision, we don't want modules inside OCA that depends
on modules outside the OCA. The main reasons are the maintainability, and
support in time. We cannot guarantee outside modules and so, we must refuse
modules that depends on them to ensure a coherence. It's also a matter of
right (module outside have no CLA and by then, OCA cannot guarantee them in
time). I'm of course in favor of letting Kaspar put his work under the OCA
umbrella, but so far he doesn't want to.

So the best option is for me also to remove the modules that depends on
Aeroo from OCA. One day things may change, and Kaspar may include his work
under the OCA umbrella.



On Mon, Jan 19, 2015 at 8:33 AM, Alexandre Fayolle <
alexandre.fayolle@xxxxxxxxxxxxxx> wrote:

> On 17/01/2015 14:12, Mario Arias wrote:
> >
> > Aeroo is a great tool, and Alistek has been working hard in making it
> > work for V8, as  S. A.  broke many basic connection points at the core
> > with the API changes....
> >
> > So Aeroo is alive and Kaspar has been really taking care of feedback
> > from other community members. Please give them a chance and do not
> > close OCA to modules using it....
> >
> > Regards,
> > Mario
> >
> >
> Hello Mario,
> The question is not whether aeroo reports is alive or not. It's whether
> OCA wants to maintain modules with dependencies outside OCA + Official
> Addons or not. So far, the answer has been "no". We tried to discuss
> including aeroo reports in the core and we were answered that Alistek
> don't whish this. My proposal is therefore to remove the "offending"
> reports from the OCA addons. Since there are only a handful of such
> addons, all in OCA/hr, and I so far have not met much resistance by
> actual users of these modules asking for OCA to keep them, I tend to
> think that there is not much harm done in their removal.
> There are 2 other solutions I can think of:
> 1.  for Aeroo reports, and maintain that fork inside OCA
> 2. change the policy
> Option 1 sounds like a waste of ressources to me, and option 2 sounds
> like an open door to many abuse in the future.
> --
> Alexandre Fayolle
> Chef de Projet
> Tel : + 33 (0)4 79 26 57 94
> Camptocamp France SAS
> Savoie Technolac, BP 352
> 73377 Le Bourget du Lac Cedex
> http://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



*Joël Grand-Guillaume*
Division Manager
Business Solutions

+41 21 619 10 28

Follow ups