openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

2010/6/23 "Borja López Soilán (Pexego)" <borjals@xxxxxxxxx>

>  Équipe informatique escribió:
>
> Also, I once filed a blueprint that you may be interested in :https://blueprints.launchpad.net/openobject-server/+spec/refactor-fields
> And XRG replied : "Please look at commit ef8d90110cfdc8 I had done at
> 2009-09-12. It is already on trunk, you can specify oldname="sth" at the
> columns you have renamed."
> Lionel.
>
>
>
> Good to know! Thanks guys, I'm learning a lot lately :)
>
> P.S. Neither this "oldname" nor the previous "migration" features are
> documented on the developer book<http://doc.openerp.com/developer/index.html#book-develop-link>or the technical
> memento <http://www.openobject.com/memento/>, that makes me think about
> how many other undocumented features might I be missing... :(
>

Borja,

IMHO, part of the reason is that OpenERP sale those migrations scripts as
part of there "maintenance contracts". While I understand that OpenERP
should find ways to get a return on their R&D investment, I fear the lack of
openness is here motivated by the willingness that migrations keep something
secret you only have if you buy a maintenance contract.

Indeed, if that were more documented, we could easily imagine the creation
of community managed migration scripts that would do the job well enough, at
least for us integrators that accept to get their hands dirty when required
(as we don't buy the Saas dream yet).
I already proposed that a few month ago on those lists and even proposed to
build them collectively by allowing the community to comment scripts
possibly using a Google Wave linked to the commit RSS so that the revision X
to Y migration scripts would just be the concatenation of the commit wise
migrations scripts contributed by the community. Might not be perfect but
would already save a ton of work and be more reliable than scripts written
in the dark by guys we don't know and without feedback how they work.

Again, I hope and find it normal OpenERP generate revenues. Still, it sucks
a bit when it comes at the price of closing code/migrations scripts. I think
OpenERP can also only success with a skilled network of partners (eg us the
real guys on Launchpad) that would follow them rather than forks. The thing
is that currently buying those scripts is not so easy for an integrator /
integrator customer (just a second level maintainance contracts weights 50%
of an OpenERP project cost in a typical 50 employees Brazilian company while
market expects the total maintenance cost to be less than 20% of the cost ->
no way) and doesn't encourage peer review/ community improvement and we
still have some reasons not to propose that service ""quality"" to our own
customers as they would then have no money left for us to work if the job
weren't done good enough which does happen from what we know (even
if admittedly things are improving luckily).

All right, I'm part of those who think OpenERP will rather success with open
migrations (may be OpenERP S.A. should then invest less on them and rather
let the partners write the scripts collectively, not sure). In any case,
it's always interesting to know that closed migration scripts have played a
large part in the Compiere fork Adempiere
http://www.red1.org/forum/viewtopic.php?t=931* *. Always interesting when
you know that Compiere has just been taken off from the open source
landscape last week.

I'm open to that debate and in any case getting knowledge of the technical
automated migration system is part of the process to more openness.
And again, I'm willing to set up the Google Wave / Launchpad commit RSS
stuff infra for community based scripts if the principle is defended enough
so that I can believe this is worth the effort.

Raphaël Valyi
*http://www.akretion.com* <http://www.akretion.com>
[image: logo_only_17 (another copy).png]