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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
