openerp-community team mailing list archive

[Peter Langenberg <peter.langenberg@xxxxxxxxxxxxx>]

+1 Joel & +1 Nicolas

I surely understand the time pressure for the release, but I think we made
an agreement.

*Here is my plan:  v8: we keep "server/report" and "report_webkit"
unchanged, but every report in our addons are converted to qweb.*

It's not a discussion, sure the qweb report has many advantages and will be
the future, but you cannot change your strategy overnight.

It's the same with the github story, ofcourse the github is better, but we
get a message on the webminar and the other day we are all github. It also
takes some time to adapt our installation scripts, to get used to this new
tool.

You know odoo has a long tail and we are member of it :-)

PS : I like the new v8, it's a good job.

Hope to see you all in june ...

Peter


2014-05-21 9:18 GMT+02:00 Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx>:

> +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
>
>