openerp-community team mailing list archive

[Olivier Dony <odo@xxxxxxxxxxx>]

On Mon, Oct 28, 2013 at 2:23 PM, Joël Grand-Guillaume <
joel.grandguillaume@xxxxxxxxxxxxxx> 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.