← Back to team overview

openerp-community team mailing list archive

Re: Could oca adopt report_webkit before v8

 

Is openerp happy to pay oca say 12 euro per user per month? Not supporting
will be large blocker to v8 adoption, maybe you should release the
automated migration tool for webkit to qweb reports, might make it easier
to accept.  Also, We will give discount for first 2 years, more than enough
time to deprecate.

Disclaimer.  Not part of oca.
On 21/05/2014 7:32 PM, "Eric Caudal" <eric.caudal@xxxxxxxxxxxxxx> wrote:

>  +1
>
> Eric Caudal*CEO*
> --*Elico Corporation, Shanghai branch
> Odoo Premium Certified Training Partner
> *Cell: + 86 186 2136 1670
> Office: + 86 21 6211 8017/27/37
> Skype: elico.corperic.caudal@elico-corp.comhttp://www.elico-corp.com
>
> *With version 8, OpenERP becomes Odoo!*
> [image: Elico Corp] [image: Odoo Silver Partner]
> On 05/21/2014 03:18 PM, Joël Grand-Guillaume wrote:
>
>   +1 For Nicolas's opinion here. I think it's fair in an open source
> project to at least give the community / partner one version to convert
> their work by deprecating something. Please, do not just remove that module
> for v8.0. You already dropped audittrail, project long term and some
> others.
>
>  If I perfectly understand all the reasons that motivate you to drop them
> (trust me;), it's the editor's duty to announce, deprecate and then only
> drop something. If you're not doing so, how can we as partners / community
> rely on you ?
>
>  Thanks for your understanding.
>
>
>  See you in june !
>
>  Joël
>
>
>
> On Wed, May 21, 2014 at 8:28 AM, Nicolas Bessi <
> nicolas.bessi@xxxxxxxxxxxxxx> wrote:
>
>> Hello Anthony,
>>
>>  I will just quote you:
>>
>>  """
>> Here is my plan:
>>
>> v8:
>>
>> we keep "server/report" and "report_webkit" unchanged, but every report in
>> our addons are converted to qweb.
>>
>> v9:
>>
>> we remove "server/report" and "report_webkit" from our repository, "
>> report_webkit" will be moved to a community repo (like we do for every
>> deprecated module).
>>
>>  """
>>
>>  It is a normal release cycle to deprate then to remove, even in
>> OpenSource.
>> Such abruts abandon of addons may not entrust people with your partner
>> contract/guarantee...
>>
>>  I also think some PR where made on branche 7 if I'm correct.
>>
>>  As I said previously, I was was my self not against abandonning totally
>> report_webkit if we can convert all our work to qweb report.
>> But doing so will take the community some time to do it.
>>
>>  Now, if you really do not want to maintain it and the question is just
>> rethoric, Camptocamp/community will maintain the module.
>>
>>
>>  Regards
>>
>>  Nicolas
>>
>>
>>
>>
>> 2014-05-21 5:25 GMT+02:00 Erdem Uney <erdemuney@xxxxxxxxx>:
>>
>>  Thank you for asking.
>>>
>>>  Weren't you the one who said about a month ago that you will support
>>> report_webkit through v8 and drop both rml and report_webkit in v9?
>>>
>>>  Regards,
>>> Erdem
>>>
>>>
>>>
>>> On Wed, May 21, 2014 at 2:36 AM, Antony Lesuisse <al@xxxxxxxxxxx> wrote:
>>>
>>>> I would like to remove report_webkit from our master branch before
>>>> releasing v8.
>>>>
>>>> I think we wont maintain it properly and i expect that this will create
>>>> frustrations during the lifetime of v8.
>>>>
>>>> None of our modules use it at all (none ever did actually). Now that
>>>> the conversion from rml to qweb/wkhtml report is done, i consider that the
>>>> default report system of v8 is superior to report_webkit.
>>>>
>>>> It has all the advantages like the speed and html/css syntax, but it's
>>>> much more modular and versatile. It supports as many layout as you want,
>>>> images and view inheritance. The codebase is also smaller.
>>>>
>>>> report_webkit was a source inspiration when we developed the v8 pdf
>>>> report generation. And i would like to thanks its author Nicolas Bessi.
>>>>
>>>> On github we already have 2 pull requests (PR) about it, i dont want my
>>>> developers to spend time on code that is not used at all by any addons.
>>>>
>>>> So report_webkit PR's will stay unprocessed and i dont think the module
>>>> deserve that.
>>>>
>>>> Would oca be motivated enough to take over the module to ensure proper
>>>> maintenance.
>>>>
>>>> Antony Lesuisse.
>>>>
>>>> _______________________________________________
>>>> 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>>
>>>
>>
>>
>>  --
>> Nicolas Bessi
>> Senior ERP consultant
>> Business Solution technical manager
>>
>> Camptocamp SA
>> PSE A
>> CH-1015 Lausanne
>>
>> http://openerp.camptocamp.com
>>
>> Direct:   +41 21 619 10 26
>> Office:   +41 21 619 10 10
>>
>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> 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
>
>

PNG image

PNG image


Follow ups

References