openerp-community team mailing list archive

[Raphael Valyi <rvalyi@xxxxxxxxx>]

On Tue, Sep 10, 2013 at 1:03 PM, Nhomar Hernández <nhomar@xxxxxxxxx> wrote:

>
>
>
> 2013/9/10 Leonardo Pistone <leonardo.pistone@xxxxxxxxxxx>
>
>> Raphael,
>> I know very well you are a contributor, and I think most people do. If
>> you say you're willing to review somewhat soon, that's fine by me.
>>
>
> Same for me.
>
> No problem mantain Raphael.
>
> BTW, if you put openly in what you are working this kind of misunderstood
> will be avoided.
>
> Our unique way to measure is the activities in the "Reviewer Team" what is
> the work in what we are working now.
>
> But if you think to finish you big job you will need the reviewer access,
> for me is fine  keep you in the team.
>

Also, as a complement, I would like to let you know that at the Brazilian
part of Akretion, we recently did a major push forward of Noviat work
around cashflow (in a 150 users/500 employees mechanical industry company),
interacting with Noviat (Luc de Meyer) and even Ana Juaristi. Polishing
that cashflow work should bring us on par with major ERP players around.
Specifically we worked on creating mixin to create cashflow lines from
other ERP managed facts with ease.
We should still test a bit more in production and polish the feedback
around this, but this is coming. In the meanwhile, this made me release
Noviat relies on their bank_statement_extension module for that (and we did
too, v6.1 project). We will need to refactor bank statement extension
modules to extract a minimal common denominator. I will happily participate
to this clean up work, but that won't be that easy as it has deep
implications with eBanking and SEPA eventually. I hope we won't end up as
fragmented the account_payment extensions modules. If we start soon enough
we have more chance to get that clean early. So at some point, the
impression you get if smb participate or not depends a bit where exactly
you look or not. And we didn't consider this to be polished enough to
bother the community with prototyping with us at these early stages.
Anyway, not trying to excuse me for little reviews these months, but just
informing you on what we have been doing and may not be immediately visible
to you, but certainly is useful in the community prospective.

Generally speaking, I think it will be important OCA chart members vote for
what modules OCA should focus or not. By trying to be too ambitious, we
loose focus from the core and decrease the quality of the core. And we
shouldn't reproduce the errors from the past with god branches gathering
too many modules with too little quality/reusability and incompatibilities
between branches as soon as you need to patch something as you often need
to the framework being what it is (with good things coming in v8
fortunately). This is specially because I have this concern in mind that
I'm ambitious regarding the git synch because IMHO this is the only tool
(or say long with hg) that is fast enough (hey unlike with bzr git-subtree
works) to seamlessly approach the one module = one branch that we will need
soon to avoid spaghetti branches again. With these bridges, we could even
think about a continuous, modules extraction into sub-branches and
continuous publication as pip modules. When we will have this, things will
be much easier when one will need to patch just one module to make it
compatible with one localization or something like that. Today, I would say
the complexity doesn't scale yet, it's just too easy people need to patch
branches in incompatibles ways at the same time and at the end it's still a
headache to maintain (though easier than in the past) and we end up too
often with branches per customers. And if it's too hard, community is too
small, integrators aren't profitable enough to grow and to maintain
themselves and that's a shot in the feet for everybody. So in a word, today
we still need these grouping branches. But in the future, that will again
hit a scalability limits we will neeed to overcome with a better tool
chain, and I've been working a bit on that, as well as others I'm sure.

Finally, ending with an optimistic note: things like fixing the on_change
API in v8 (as it seems to be done in Raphaël Collet's 'rco' branch) will
dramatically improve this situation of incompatible modules.


Regards.

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