openerp-expert-framework team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On 10/26/2011 03:32 PM, Raphael Valyi wrote:
> 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.

It's processed bit by bit based on the individual skills of the R&D
reviewers. The consequence is that less sensitive merges (like small
bugfixes etc.) may be processed more quickly that core refactorings or
controversial changes that require more internal testing and validation.

That should not be taken as a signal that they're considered less
important, just that they require resources that are scarcer than the
others. And there's no chance some will be lost/forgotten, they're all
in the +activereviews list.


> 1. module purchase picking creation:

As you said, we already validated and merged a similar refactoring, so
this one should go the same way if you applied the same logic, nothing
to fear.


>  2. same modularization and database / ORM layer optimization when
>     creating an invoice from a picking

ditto


>  3. correction of our Brazilian chart of account + related fiscal
>     codes

There are 2 versions of this controversial merge prop (6.0 and trunk),
and both have received comments since their creation. You might want to
answer the last comment on the trunk MP.


>  4. server: JSON implementation of sparse field to easily adapt to EAV
>     schemas or offer No-SQL / Document capabilities to OpenERP

This implementation was designed collaboratively with our R&D so there's
no problem to foresee for the merge, once everything is double-checked.
Nothing prevents you from using it already, the API should not change.


> If I receive some positive signal about those merges, I could contribute
> yet an other little sanity re-factoring of invoice generation

We've helped shape up, discussed and approved a lot of community MPs
this year, and many have already been merged (way more than you think).
Lots of positive signals, especially e.g. compared to one year ago!

We have limited resources, be patient, we announced we would finish
reviewing the merge proposals before making the final 6.1.
And for the future (after 6.1), we hope to achieve almost-realtime MP
review processing, just like 6.0 marked the beginning of almost-realtime
bug processing.


> If you have some availability, feel free to review those merge
> proposals

MP reviews from the community are most welcome indeed, and it's great to
see more and more cases where community members go further than
commenting "yes we need that" and actually go and review the code! :-)
You don't need any special skills to review, just read other reviews and
choose one MP to start, you'll learn as you go.

Thanks a lot to all contributors for your patience! Please bear with us
while we strive to complete 6.1 and review MPs in the process...
Hopefully this will be much faster for next version!