openerp-community team mailing list archive

[Fabien Pinckaers <fp@xxxxxxxxxxx>]

> For option 3) I'm also feeling that community need this freedom of changing such thing if members agreed on that. Currently very few as Stefan pointed out (3 DB changes).
> 
> OCB is working because he is the way it is now. Changing it would be nefast I think. Keep it the way it is is my vote.

Joel,
Sorry, but I think you lie to yourself; ocb is not working.

- several bugs have been introduced in only 60 commits
- several undesirable changes have been introduced; some going in an opposite direction than the stable one
- no real code review process is applied (several MP have +1 but patches are applied without having been really tested)
- one can not use it in production since you can not easily do "bzr pull" to apply latest bugfixes
- since ocb diverge from stable, you will have to maintain a fork and redo everything when v8 will be released
- no real tests and integration server used in the code review process. Issues are detected after having been merged.

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.

We have a good opportunity with ocb to benefit from community contributions to fasten bugfixes adoption to the stable. But the way it is now makes ocb totally unuseable in production.


If ocb apply the same process and guidelines than the stable, both ocb and the stable will benefit from this. The comunity can merge its fixes faster in ocb, we can merge ocb to stable, and the changes we revert or rewrite during our stable code review can be remerged to clean ocb. both branches will have a higher level of quality.

In the other end, if you continue diverging from the stable; the problems you have now will increase more and more. And v8 will probably be the end of ocb.

The advantage of ocb is faster bugfixes. The advantage of the stable is a higher quality and less regression. By syncing both, you will benefit from both.

If ocb diverge from the stable, you will have a trade quality and regredssion against wishlist/faster fixes.

Olivier is right here:

> So it's very simple: if the OCB contributors find it useful to have a faster commit path to the stable branches, then they might find that respecting the stable policy somehow is worth it. It's an easy way to give more power to the community. After a few iterations we might even find that the OCB team gets so good at fixing things the right way that it becomes possible to increase the OCB-to-official merge frequency. And because it brings a benefit to OpenERP SA (faster/cheaper MP reviews/bugfixes) we'll be able to commit resources to this process.



> On the other hand if this process does not seem worth it, then no problem, we'll keep merging the MPs to stable directly, and the OCB team is free to use runbot to help their reviews.

Same for me, we will support your decision but my personal opinion is that ocb will become useless /buggy /complex to maintain if you diverge from the stable.

> Additionally, I would love to see an updated statement of the goal and purpose of the OCB initiative, as perhaps the situation has evolved a bit since their inception [1].
> My initial understanding of the OCB purpose was the following:
> 1. backport fixes done on trunk to older stable branches, as OpenERP SA might only fix trunk unless an OPW ticket requires it. For 7.0 this is currently not needed [2]
> 2. speed up merging bugfixes that are waiting for review on Launchpad
> 
> However it seems the following goals have been considered desirable too:
> 3. allow schema/API/... changes that are not allowed by the OpenERP stable policy (presumably to fix bugs in a different manner from the official branches or to implement wishlists)
> 4. implement nice-to-have changes that are considered wishlists in the official version
> 5. change design decisions such as default behaviors or values (outgoing emails, etc.)

> Normally the OpenERP design would require these 3 categories of changes to be done in extra modules instead of patching the core, especially because this would more easily survive conflicts and new releases.

I agree with Olivier.


> Otherwise you're going to have to maintain this as a regular fork (Unless the changes are proposed to trunk and accepted, but what about those who are not?!)
> So how do you plan to handle this? What will become of your 7.0 divergences once 8.0 is released?



> Defining this clearly seems critical in order to shape the future of the OCB branches.



Thanks for this great initiative,


> Many thanks!
> 
> 
> [1] http://openerp-community.2306076.n4.nabble.com/Openerp-community-Proposal-for-a-community-backports-project-td4641940.html
> [2] Most fixes that apply to 7.0 have been done directly in stable since the release of 7.0 (see the commits on 7.0 vs trunk). Indeed most issues in trunk are still present in 7.0 at the moment, and we have a semi-automatic forward-port of 7.0 to trunk, so it's almost as fast and cheap for R&D to fix directly in 7.0. And it's even better for the users.
> _______________________________________________
> 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