openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Mon, Apr 28, 2014 at 11:25 PM, Antony Lesuisse <al@xxxxxxxxxxx> wrote:

> Sorry for being rude, my point here was simply that if somebody really
> wants something it's probably easier to work on it than to convince someone
> else to do it.
>
> For OpenERP Enterprise customers, our the migration service will find a
> solution for a smooth upgrade path on specific basis. (most likely
> base_action_rules). Maybe they will fix the module to make it work for v8.
> But this will happen after june.
>
> We decided to move auditail to extra (with other modules) as we think they
> dont meet the quality standard for a long term release and we have
> alternative solutions to the use case (althought not fully equivalent).
> Auditrail in trunk is broken since 1 year and the only MP about it was made
> by Stefan Rijnhart 2 years ago.
>
> I want to close the merge window for v8 and we will merge wms this week
> and new api next week (not sure 100% yet). So even if we fix auditrail it
> will be later and the module wont be part of v8.
>

Hello Antony,

I respect the concern of impacted people, but I also agree that is was
shitty code and I'm not angry when OpenERP SA is focusing on the core
modules.

But as you are talking about feature freeze, I'm squatting the thread to
react to this important topic that never has a chance to surface: during a
release life cycle we are often opposed that merge proposal X cannot be
done because it would break the API or the database schema.
But sometimes this is really a major hassle for modules depending on
OpenERP, such as the localizations because modules are badly incompatible
between them where the average OpenERP customer would expect things work
out of the box when adding modules.

I also understand you don't have enough resources to review the hundreds of
community merge proposals submitted every year.

But is there a way the OCA or whatever other form of community organization
could promote a limited set of merge proposals focused on the API and only
on the API changes?

In a good release policy, you use something like semantic versioning and
you really take advantage of new major release to concentrate the necessary
API evolution. Most of the bugfix on the contrary can happen later without
requiring API changes. Many new feature can also happen in extra modules
without monopolizing the focus of the new release. But API change should
take place during these rare moments. This has really a lot's of
consequence on the size of the overall OpenERP user base later. Bad API ->
bad localization / incompatibles verticals -> no user, no business etc...

A concrete example of what I'm talking about is:
https://code.launchpad.net/~camptocamp/openobject-addons/trunk-refactor-po-merge-lep/+merge/216841
(code to make merging purchase order modular so extension modules can
inject their proper behavior)

Is there a way and a deadline, OCA can do the sorting work to promote you
the most required while simplest API evolutions?


Regards and kudos for the work on v8


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