openerp-expert-framework team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

Hello OpenERP experts,

Recently Fabien was promoting the concept of distributed project vs
centralized, and recommending us to do merge proposals
http://www.openerp.com/forum/post93168.html#p93168
I can only agree, but facts is we proposed many merges for 6.1 and they are
very seldom evaluated and this is frighting us a bit as those tend to be
mostly elementary refactoring we have been needing in OpenERP for years.
I think house cleaning refactoring should be given priority over new
features in the core. New features can often be added later in the release
life cycle in external modules, while API refactoring is often rejected so
we need to take advantage of the rare occasions during new releases. Also,
from what I understand OpenERP SA do little integration now while we do that
all the day. Hence it seems essential that community merge proposals should
be evaluated by OpenERP SA otherwise our ground experience and need for
other localization is missed totally or progressing too slowly. Despite more
than 300 partners, dozens of proposals and potentially a lot more if given
some positive signal, I've seen less than around 10 community merges in the
addons over the last 4 months and this is why I'm writing this email.

I'm not sure what is OpenERP internal organization and how the merge pipe
https://code.launchpad.net/~openerp/openobject-addons/trunk/+activereviews is
evaluated.
So, I will here briefly list merges from Akretion we hope to get in 6.1 (at
least rejected for some reason else):


   1. module purchase picking creation:
   https://code.launchpad.net/~akretion-team/openobject-addons/addons-purchase-extensible-action-picking-create/+merge/79485
This
   is very much he same logic as what you recently merged from us concerning
   the sale picking generation. The idea is to avoid overrides from modules to
   hit the database and ORM layer (specially fields.funcion + store) over and
   over and to have modules more compatible between them thanks to a more
   modular API. This is specially useful in localization modules such as the
   one we are leading in Brazil where lot's of fiscal fields need to be
   propagated from the purchase to the invoice. BTW, as previously announced, I
   want to improves the modules for dealing with drop shipping and I think that
   would be a shame doing it in a nasty brittle way because we don't merge this
   API improvement.
   2. same modularization and database / ORM layer optimization when
   creating an invoice from a picking
   https://code.launchpad.net/~renatonlima/openobject-addons/addons-stock-extensible-action-invoice-create/+merge/78181

   3. correction of our Brazilian chart of account + related fiscal codes
   https://code.launchpad.net/~renatonlima/openobject-addons/l10n_br_merge_trunk/+merge/77957
waiting
   for more than 5 months now. I cannot understand OpenERP SA is using us to
   train 80% of the new Brazilian partners and giving their salesmen
   OPW/partnership targets here if on the other hand all the basic localization
   efforts we have been making during 2 years are ignored by OpenERP SA.
   Without this, the average users (and even many less experimented other
   official partners) sees double due amount in their invoices or are unable to
   install the other localization modules...
   4. server: JSON implementation of sparse field to easily adapt to EAV
   schemas or offer No-SQL / Document capabilities to OpenERP
   https://code.launchpad.net/~akretion-team/openobject-server/sparse_field/+merge/67105
We
   received a positive feedback from OpenERP SA but no merge yet. This is
   annoying as all the trunk version of the Magentoerpconnect Magento connector
   is now based on that patch to offer much better performances when dealing
   with the EAV Magento schema. We are also about do make a deal to improve the
   product configurator I made for v5 back to 2008 and and I plan to use some
   of those JSON attributes when a production order has to be customized on
   demand.

If I receive some positive signal about those merges, I could contribute yet
an other little sanity re-factoring of invoice generation from picking (in
Brazil for instance service can not be on the same product invoice, so
currently services is re-attached and re-deleted by our override, nice...)
or also for progressive invoicing from order (useful for long term
projects). But you will understand that without merge feedback, one only has
the impression to loose time trying hard to contribute to the OpenERP
project.

If you have some availability, feel free to review those merge proposals, as
I think it can help OpenERP SA to make decision quicker about them, but of
course all this makes sense only if we are not just loosing our time here.

Finally don't take me wrong, I'm not urging for a release by no means. It's
just that I've seen bugs flagged as RC1 and usually RC1 means code is
expected frozen. This is the half assumed presence of this RC1 tag vs the
quantity of unqualified pending merge proposals that is leading me to write
this email. If you plan to merge in 2 weeks and release in 1 month, no
problem, it's just that we need information to make decision on pour
projects.


Regards and good luck for the release. BTW demand is increasing steadily in
Brazil, I just hope OpenERP 6.1 will meet the market expectation enough
without having to wait one more year for basic cleanup.


-- 
Raphaël Valyi
Founder and consultant
http://twitter.com/rvalyi <http://twitter.com/#!/rvalyi>
+55 21 2516 2954
www.akretion.com