Server Environment And Tools

Code review comment for lp:~gdgellatly/server-env-tools/base-synchro-7.0

base-synchro-7.0
Merge into 7.0

Revision history for this message

Graeme Gellatly (gdgellatly) wrote on 2014-01-23:

My opinion is a bit like Stefan's. We have something that works now, maybe it is not the future, but it works. If someone wishes to completely redo the way it works then all fine by me, if they want to replace it with something better, but as such a thing does not yet exist I would argue that an imperfect module is better than someones imagined perfect module today, installing thin air is difficult. It does a job in many use cases.

The only reason I refactored it is someone paid me to, asking me to base of this module, not emotionally attached here had never even heard of it until 6 weeks ago. For them it works well so I contribute back to the world at large. I'm sure if there are problems or other features required they will pay me some more and I will contribute some more. If that contribution is unwanted by the community then makes no difference to me, I have to support either way. If it reaches a point where base_synchro is no longer the answer (and my inital proposal was ETL) then we will evolve, simple as that.

As for the 3 technical issues, actually they are not so hard to address, however they are not introduced by the port but pre exisiting issues which have been partially addressed already. I've taken the module as far as I am willing so far, but have left notes for future contributors.

As for the last point, the language is a bit strong. OpenERP no longer support but still do use and indeed just this week Fabien defended base_synchro as useful in many cases. The statement implies the editors abandoned due to bad design, actually that is not the case, but more in favour of simplification. Besides there are examples of abandoned modules base_contact, product_variant_multi to name a couple which still receive widespread community attention so abandonment on its own I don't really see as a justification.

In any case my basic opinion is this. It is better than nothing, builds on the work of what has come before, and better than any imagined future right now. If someone wants to spend the time realising that future based on the openerp-connector (or anything else) then great, develop it and make a merge proposal, even deprecating this module.

I'm all for evolution, but I think if we start proposing rejecting merges for imagined futures rather than against delivered outcomes then we are perhaps overreaching the remit of review. What guarantee do we have of this dream ever being realised for v7, or indeed ever. It would be different if an alternative existed for sure.

Indeed if not for OpenERP's initial work then SerpentCS initial v7 proposal and my instructions to use it then the pushing forward to today's state would not have been possible. I like to think the module contains enough new ideas that even if today is the end of its lifetime it helps in some way guide replacement efforts.

My opinion is a bit like Stefan's.  We have something that works now, maybe it is not the future, but it works.  If someone wishes to completely redo the way it works then all fine by me, if they want to replace it with something better, but as such a thing does not yet exist I would argue that an imperfect module is better than someones imagined perfect module today, installing thin air is difficult.  It does a job in many use cases.

The only reason I refactored it is someone paid me to, asking me to base of this module, not emotionally attached here had never even heard of it until 6 weeks ago. For them it works well so I contribute back to the world at large.  I'm sure if there are problems or other features required they will pay me some more and I will contribute some more.  If that contribution is unwanted by the community then makes no difference to me, I have to support either way.  If it reaches a point where base_synchro is no longer the answer (and my inital proposal was ETL) then we will evolve, simple as that.

As for the 3 technical issues, actually they are not so hard to address, however they are not introduced by the port but pre exisiting issues which have been partially addressed already.  I've taken the module as far as I am willing so far, but have left notes for future contributors.

As for the last point, the language is a bit strong.  OpenERP no longer support but still do use and indeed just this week Fabien defended base_synchro as useful in many cases.  The statement implies the editors abandoned due to bad design, actually that is not the case, but more in favour of simplification. Besides there are examples of abandoned modules base_contact, product_variant_multi to name a couple which still receive widespread community attention so abandonment on its own I don't really see as a justification.

In any case my basic opinion is this.  It is better than nothing, builds on the work of what has come before, and better than any imagined future right now.  If someone wants to spend the time realising that future based on the openerp-connector (or anything else) then great, develop it and make a merge proposal, even deprecating this module.

I'm all for evolution, but I think if we start proposing rejecting merges for imagined futures rather than against delivered outcomes then we are perhaps overreaching the remit of review.  What guarantee do we have of this dream ever being realised for v7, or indeed ever.  It would be different if an alternative existed for sure.

Indeed if not for OpenERP's initial work then SerpentCS initial v7 proposal and my instructions to use it then the pushing forward to today's state would not have been possible.  I like to think the module contains enough new ideas that even if today is the end of its lifetime it helps in some way guide replacement efforts.

« Back to merge proposal