openerp-community team mailing list archive

[Stefan Rijnhart <stefan@xxxxxxxx>]

On 10/28/2013 11:07 PM, Fabien Pinckaers wrote:
> Joel,
> Sorry, but I think you lie to yourself; ocb is not working.

Wooah Fabien,

that is a lot of FUD that you are spreading if you pardon me saying so. 
Let's get some of the facts straight.

> - several bugs have been introduced in only 60 commits

As I mentioned earlier in an earlier reply to you, this is not true. So 
far only tests had to be updated to anticipate the modified (or IMHO, 
improved) behaviour of OCB.

> - several undesirable changes have been introduced; some going in an 
> opposite direction than the stable one

Well, it's hard to know what the direction of the stable one is exactly, 
when bug reports are ignored or confirmed and then moved to 'won't fix' 
or 'invalid' later on. And that is not to say that OpenERP SA can't do 
that. I'm perfectly fine with it but it simply means that we have to 
find out for ourselves what we think should go into OCB. And we just 
have to deal with each of these changes in the transition to OCB-8.0. 
It's not your problem.

> - no real code review process is applied (several MP have +1 but 
> patches are applied without having been really tested)

You should be jealous. OCB has 100% reviewed code even if not all 
changes are tested. At the same time we still see the occasional OpenERP 
core dev reverting their own unreviewed patches a day later.

> - one can not use it in production since you can not easily do "bzr 
> pull" to apply latest bugfixes

I don't even know what you mean by this. I pull OCB-branches on a daily 
basis. Because of the nightly replay process, they are never more than a 
day behind the official ones.

> - since ocb diverge from stable, you will have to maintain a fork and 
> redo everything when v8 will be released

Yes, but only if we want to (see above).

> - no real tests and integration server used in the code review 
> process. Issues are detected after having been merged.

See above, and open for improvement.

> If I raise such a warning, it's not to criticise ocb. It's great to 
> have such contributions and I think ocb can be very usefull if done 
> correctly.

Well, the same can be said about OpenERP ;-) Its bug fixing policy is 
broken by design. Just today I saw an OPW fix to get those damn purchase 
orders in state 'done', which bypassed the workflow engine completely. 
When I asked why it could not be fixed properly, the author replied that 
the bug fixing policy did not allow any changes to the workflow. So the 
policy dictates that a broken part of the system gets patched up with a 
broken fix. I honestly hesitate to propose this particular fix into OCB, 
even if the author did the best that could be done within the 
limitations of the policy.

I understand that the bug fixing policy is due to the out-of-the-box 
implementation strategy, where the consultant makes a lot of changes in 
the interface that would not survive a module upgrade. OCB is not for 
them. That strategy is not for us. None of us is going to change 
position on this. From your point of view, OCB is broken. From ours, it 
is excellent.

So we still disagree (no surprises there) but OCB is working perfectly 
for us. When running OCB, we can be sure that every approved bugfix that 
we supplied is included so that we don't encounter the same bugs again 
for every customer. A dedicated group of community developers (and their 
customers) is benefiting from each other's quality bugfixes and reviews. 
I love it. It has taught me a lot on programming, communities, code 
standards and OpenERP itself. It has improved my life with OpenERP in 
terms of practicalities and got me in contact with a lot of knowledgable 
and friendly people that I now consider my extended colleagues.

And if OpenERP SA sees fit they can benefit from us running these couple 
of handfuls of fixes in production and from our reviews on backported 
OPW fixes and if they don't that is fine too. And if we can make it a 
little easier for SA without disturbing the OCB collaborative process 
too much then we will surely do that.

Cheers,
Stefan.

--
Therp - Maatwerk in open ontwikkeling

Stefan Rijnhart - Ontwerp en implementatie

mail:stefan@xxxxxxxx
tel: +31 (0) 614478606
http://therp.nl
https://twitter.com/therp_stefan