On Mon, Oct 28, 2013 at 2:23 PM, Joël Grand-Guillaume < [email protected]> wrote:
> Dear all, > > A bit late, but better late than never... I completly share Stefan's > vision here. I'm also inline with what suggested Olivier during the > community days ans I'm also happy to see this "Respawning" ! > > > 1/ The OCB branches would need to be relocated under the official projects > 2/ The OCB branch management process needs to be adapted accordingly > 3/ Compliance with the OpenERP stable policy [2] should be added to the > review checklist for OCB branches, and the current branches reviewed in > this light > Hi Joel, thanks for your feedback! 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. > Sure, though I'm not sure OCB is working *because* the OCB policy is less strict that the OpenERP stable policy. Though again, it's fine for me if the OCB contributors insist on having a different policy. But you have to understand that it will not be possible to setup a semi-automated OCB-to-official merge process if there is such a divergence. Cherry-picking the changes is not an option because at that point it's easier to merge/reject the regular merge proposals on the official branches. And partially reverting the upstream changes to ignore some changes will break the upstream merge back into OCB, so it does not work either. 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. 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. 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. 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 : [email protected] Unsubscribe : https://launchpad.net/~openerp-community More help : https://help.launchpad.net/ListHelp
