2013/2/11 Joël Grand-Guillaume <[email protected]> > 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
_______________________________________________ Mailing list: https://launchpad.net/~openerp-community Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
