openerp-community team mailing list archive

[Niels Huylebroeck <nh@xxxxxxxxxx>]

2013/2/11 Joël Grand-Guillaume <joel.grandguillaume@xxxxxxxxxxxxxx>

> 2) Reviewing the MP on the core will take even more time than reviewing
> the community projects. We'll need to test every proposal and we'll not be
> able to "just" have a look on the code.
>
> Once again, I just want to reflect the fact, I do not mean to criticize.
> Everybody invest the time he can, at a point we (meaning here the
> community-reviewer team) may decide to vote for removing people that simply
> cannot invest time, but this is another story.
>
> Then, starting from those fact, the Camptocamp point of view is that we
> are in favor of making such a community branch, but we will not be able to
> provide the needed resources to review this work. We already making
> everything we can to assume the review on the current community
> projects. At the end, it's a community decision. Camptocamp is in favor of
> putting those branches there, but won't be able to assume all the work.
>
> So, what are your opinion ? Who can invest time to help review those new
> branches ?
>
>
Let's take a step back here, what you're basically asking is that the
community will painstakingly compare OpenERP core with your branches where
you have been applying patches that have never been sent to OpenERP and
were only "tested/confirmed" by your customers.

We at Agaplan take a different approach than your
patch-make--private-branch: for each bug however small we file a bugreport
and if appropriate create a branch with a fix (using the lowest version
according to the DaggyFix principle). We then spend literally hours
communicating with OpenERP to get each bug fixed by merging our branches.
Some of these happen some are flat out rejected and others are re-invented
in surprisingly identical ways...

When they are fixed/merged we have contributed (by saving time) to the
community for everyone to benefit because it is a validated and officially
supported solution to the bug.

Your approach sounds to me more like: we will spend 5 minutes to fix a
problem for our customer, throw it in a branch which we use and then ask
the community to verify the whole diverging you have done from the official
branches ? This to me sounds lazy because you don't contribute back to the
project at all (you may think you have but unless your code is 100%
verified AND integrated into the official addons you are the only one
having a benefit from your "contributions").

In fact by asking the community to verify your branch for you, you are
burdening the community with a lot more work which could've been avoided by
communicating with OpenERP and tracking your own fixes in different
branches.

And yes this is hard process, but compare the amount of work fighting
individual issues against the huge branch you are now trying to slap on top
of the official addons.
We too have considered the "private-branch" approach and in fact we found a
middle ground, for production installations we install a branch on which we
apply our own merge requests if the customer requires a fix urgently, then
when OpenERP finally accepts this branch we will never have any trouble
re-doing a merge from the official addons.

-- 
Niels Huylebroeck
Lead Architect   --   Agaplan
Tel. : +32 (0) 93 95 98 90
Web : http://www.agaplan.eu