openerp-community team mailing list archive

[Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>]

Dear Raphaël,


I never mean here (and never will) that you do not contribute to OpenERP !!

The thread here is about having an OpenERP Community Reviewer team with
active people in it. That's not the same. You do contribute a lot,
everybody agree on that. But without any harm, you are not making review.
That's 2 different things.

We all had one year (a bit less) to prove our investment here, and trust
me, I do not have lot of time in there either, but I try at least to give
some time every month for it.

So, if you say you still want to review and take time for this, fine for
me, I'm more than happy trust me ! That's a good news :)

Cheers,


Joël





On Tue, Sep 10, 2013 at 6:36 PM, Raphael Valyi <rvalyi@xxxxxxxxx> wrote:

> 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
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-community
> Post to     : openerp-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-community
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 


*camptocamp*
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS

*Joël Grand-Guillaume*
Division Manager
Business Solutions

+41 21 619 10 28
www.camptocamp.com