openerp-fiscal-rules

Code review comment for lp:~renatonlima/openerp-fiscal-rules/fiscal-classification

fiscal-classification
Merge into 7.0

Revision history for this message

Joël Grand-Guillaume @ camptocamp (jgrandguillaume-c2c) wrote on 2013-01-17:

Dear Raphaël,

I cannot understand your comments here, I'm really sorry. I cannot admit you're speaking about us this way without saying a word. We're talking about the rules that community agree to follow, not quality of your code nor the fact that you're the author, either not that you're code is stable or not. Don't mixed up everything please.

First of all, we're not talking about Akretion's investment in the OpenERP's world, in term of contributions, effort, time, and more. We both know how much we invest here ! That's why we, Camptocamp and Akretion, work hands-in-hands on various topics, with friendship, peace and at the end a win-win situation.

Then, we know you're making all the effort on Brazilian localization, we know that's hard work. Now, do not talk about what you don't know. Do not says "it's a very tough reality that you at Campcocamp would be far from assuming when you want to raise 150k euros just to refactor the Magento connector for v7...". We also assume the devs of thousands lines of code before you even had a look on OpenERP ! All this work was done without one $ from anybody else but Camptocamp. Most of those devs are now part of the core now-days, everybody benefit from it and that's the fantastic Open Source world.

Regarding the connector devs, could I remind you that we already make workshops, talks, specifications and all the rest, sharing everything with Sebastien Beau from your team months before publishing something !? As far as I remember, we now share specs and how we though to build the new generation with the whole community. We already plan to make a code sprint with you all. How the hell can you just ask Guewen where is his code !? Do you really think we won't have the community to review it ? It doesn't seems to be in our habits if you just look at the merge proposal review list.... Without asking a penny, Camptocamp make most of the reviews , and from far !

Finally, regarding the funding on the connector, we though it'll be fare to ask others to contribute on it as it's not always at Akretion, Camptocamp or some core contributors to fund everything. We already, as you've done, put a lot of money here. It seems fair to ask for some other beneficiary to invest a bit. And your team agree on that (or at least Sebastien did).

I don't want to sound harsh, but do not push the button to far away here, this is something I do not like at all. I can understand you're a bit angry regarding Stefan and Guewen answer on you merge. But that's the rules that everybody agree to respect.

You don't want those constraints (that I more see like a benefit), well, put your module in your own branch as you mentioned. No big deal for us if you feel more comfortable with that. But in the community branch, rules must be followed without exceptions. If you do need a quick review, just write to the reviewer mailing, I'm sure somebody will review it in the same day. Moreover, most of the review are made in 2-3 days, we're not at OpenERP ;) and it'll be even faster if you jump in :) ! If you want to continue the debate or suggest other rules please, post your suggestions on the reviewer mailing list (<email address hidden> ). I'm not making the rules alone and everybody has his voice here.

Good luck for your localization work, I see that's taking all your efforts. Hope you're seeing the end of the tunnel.

Cheers,

Joël

Le 17 janv. 2013 à 14:51, Raphaël Valyi - http://www.akretion.com <email address hidden> a écrit :

> Dear Guewen and Stefan,
>
> really I like the community review system and I promise we will submit ourselves to it the more possible. And as you can remember we are the one who spent an absurd amount of time to build the branch extraction scripts that just made the modularization possible...
> Now really I think that there should have some exceptions and if you think about it, you'll see even you aren't doing any different.
>
> So first of all Guewen, I don't want to sound harsh, but are you doing any different when you claim to rewrite the Magentoerpconnect project in v7? I'm already working on refactoring the lower level dependencies of it too... Where are these nice code review on your early prototypes? How is that different from the refactor we do in our localization?
>
> Now about the fiscal_classification module: it happens it's a module we built for the Brazilian localization but with the hope it could be useful to other countries and this is the reason it's not built in our localization branch. But to day we are unaware of any thord party using it unfortunately... Still we promise we will do demo videos to explain the module better to get more chances to increase its adoption.
>
> Now our business reality is that while OpenERP SA is selling partnerships to competitors leeching at our code and project image without never contributing a single line of code, just Renato Lima and me are carrying around over 15 000 lines/ 21 modules of localization alone. As you can see: it's a very tough reality that you at CampToCamp would be far from assuming when you want to raise 150k euros just to refactor the Magento connector for v7... So I mean, almost nobody is doing what we do in the conditions we do it and unfortunately it means we have to do it the way it can work for us. And the way it can work for us isn't having to wait for people who never used that code to review every little commit we do in the version; unfortunately.
>
> So depending on your company size, location, market, maturity, realities are VERY different. You could think that only CampToCamp reality is valid. Well I would say that NONE of the larger/more comfortable companies did a tenth of what we did for our localization (or even for the Magento connector until quite recently BTW), so I think this is a clear sign that every business reality is valid and not adapting to these micro scales realities would be a terrible loss for the OpenERP eco-system.
>
> By the way, that code as already been deployed in production in a 400 employees companies last month, so it isn't too experimental either (now the former version was utterly borken for such usage).
>
> So again, I think module authors should be allow to opt'in for review or not if they are refactoring for new OpenERP versions. If that is not possible, well, what would happen is that we would simply move out our module from that reviewed branch (that we had started BTW) and used an unreviewed branch as the main branch. I don't think such an extremity is a good idea at all.
>
> Instead what I think is that it's better to maximize code review but without being fanatic about it. That is: everytime you touch a third party module, you submit yourself to the review unless the change is trivial, evertime you touch a production ready module, you submit yourself to the review and the rest of the time, you try to do it when it's possible, that is not always unfortunately.
>
> In a word, we are coming from a terrible chaos. We target a better world. That transition isn't going to happen from one day to another, we have to be flexible to allow a possible transition to better ways of working.
>
> I hope you understand.
> --
> https://code.launchpad.net/~renatonlima/openerp-fiscal-rules/fiscal-classification/+merge/143393
> Your team Account Core Editors is requested to review the proposed merge of lp:~renatonlima/openerp-fiscal-rules/fiscal-classification into lp:openerp-fiscal-rules.

Joël Grand-Guillaume
Division Manager
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
http://openerp.camptocamp.com/

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: <email address hidden>

Dear Raphaël,

You don't want those constraints (that I more see like a benefit), well, put your module in your own branch as you mentioned. No big deal for us if you feel more comfortable with that. But in the community branch, rules must be followed without exceptions. If you do need a quick review, just write to the reviewer mailing, I'm sure somebody will review it in the same day. Moreover, most of the review are made in 2-3 days, we're not at OpenERP ;) and it'll be even faster if you jump in :) ! If you want to continue the debate or suggest other rules please, post your suggestions on the reviewer mailing list (openerp-community-reviewer@lists.launchpad.net ). I'm not making the rules alone and everybody has his voice here.

Good luck for your localization work, I see that's taking all your efforts. Hope you're seeing the end of the tunnel.

Cheers,

Joël

Le 17 janv. 2013 à 14:51, Raphaël Valyi - http://www.akretion.com <rvalyi@gmail.com> a écrit :

> Dear Guewen and Stefan,
> 
> really I like the community review system and I promise we will submit ourselves to it the more possible. And as you can remember we are the one who spent an absurd amount of time to build the branch extraction scripts that just made the modularization possible...
> Now really I think that there should have some exceptions and if you think about it, you'll see even you aren't doing any different.
> 
> So first of all Guewen, I don't want to sound harsh, but are you doing any different when you claim to rewrite the Magentoerpconnect project in v7? I'm already working on refactoring the lower level dependencies of it too... Where are these nice code review on your early prototypes? How is that different from the refactor we do in our localization?
> 
> Now about the fiscal_classification module: it happens it's a module we built for the Brazilian localization but with the hope it could be useful to other countries and this is the reason it's not built in our localization branch. But to day we are unaware of any thord party using it unfortunately... Still we promise we will do demo videos to explain the module better to get more chances to increase its adoption.
> 
> Now our business reality is that while OpenERP SA is selling partnerships to competitors leeching at our code and project image without never contributing a single line of code, just Renato Lima and me are carrying around over 15 000 lines/ 21 modules of localization alone. As you can see: it's a very tough reality that you at CampToCamp would be far from assuming when you want to raise 150k euros just to refactor the Magento connector for v7... So I mean, almost nobody is doing what we do in the conditions we do it and unfortunately it means we have to do it the way it can work for us. And the way it can work for us isn't having to wait for people who never used that code to review every little commit we do in the version; unfortunately.
> 
> So depending on your company size, location, market, maturity, realities are VERY different. You could think that only CampToCamp reality is valid. Well I would say that NONE of the larger/more comfortable companies did a tenth of what we did for our localization (or even for the Magento connector until quite recently BTW), so I think this is a clear sign that every business reality is valid and not adapting to these micro scales realities would be a terrible loss for the OpenERP eco-system.
> 
> By the way, that code as already been deployed in production in a 400 employees companies last month, so it isn't too experimental either (now the former version was utterly borken for such usage).
> 
> So again, I think module authors should be allow to opt'in for review or not if they are refactoring for new OpenERP versions. If that is not possible, well, what would happen is that we would simply move out our module from that reviewed branch (that we had started BTW) and used an unreviewed branch as the main branch. I don't think such an extremity is a good idea at all.
> 
> Instead what I think is that it's better to maximize code review but without being fanatic about it. That is: everytime you touch a third party module, you submit yourself to the review unless the change is trivial, evertime you touch a production ready module, you submit yourself to the review and the rest of the time, you try to do it when it's possible, that is not always unfortunately.
> 
> In a word, we are coming from a terrible chaos. We target a better world. That transition isn't going to happen from one day to another, we have to be flexible to allow a possible transition to better ways of working.
> 
> I hope you understand.
> -- 
> https://code.launchpad.net/~renatonlima/openerp-fiscal-rules/fiscal-classification/+merge/143393
> Your team Account Core Editors is requested to review the proposed merge of lp:~renatonlima/openerp-fiscal-rules/fiscal-classification into lp:openerp-fiscal-rules.

Joël Grand-Guillaume 
Division Manager
Business Solutions

Camptocamp SA
PSE A, CH-1015 Lausanne
http://openerp.camptocamp.com/

Phone: +41 21 619 10 28
Office: +41 21 619 10 10
Fax: +41 21 619 10 00
Email: joel.grandguillaume@camptocamp.com

« Back to merge proposal