1. Mailing Lists
  2. Contributors
  3. Re: The future of OCB → fork and consolidation

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

A little reward for code sprint participants

Re: Thank you for your participation in Business Requirement workshop

Avatar

Re: The future of OCB → fork and consolidation

by
TAKOBI s.r.l., Lorenzo Battistini.
- 05/10/2016 15:59:20
A fork would have a lot of implications that we all already know: the community would be divided and the efforts duplicated.
Also, we would totally lose the contributions from odoo SA, that are huge. Both in terms of new functionalities and in terms of fixes and refactoring. See the recent porting to new API of every core module.

I really don't see how the separation of the core framework from the addons would be a valid reason to split the community.
And, anyway, you know where to find tryton, if you need something like that.

I am not against OCX, provided that odoo branches will be continuously merged into OCX (even if I am not sure it will be easy and I personally don't feel the need of such a new version of OCB)

Regards



On 5 October 2016 at 14:38, Christophe Combelles <ccomb@anybox.fr> wrote:

I'm totally in favor of pushing forward the idea of a replacement project, divergent branch, separate work, or fork, name it as you want! I even think this work should have been done at least one year ago.  Below is my own vision, maybe similar to what's Stefan is tasking about.

I feel like the current state is : we have a less and less useful OCB branch, base on a less and less useful Odoo Community stripped down version.  If the community wants to offer a viable open-source version, both for integrators and developpers, I believe we need TWO things :

  • First of all, we need a separation of the core framework from the addons. History proves me that it is dangerous and not durable to heavily extend the standard addons for a given project. For many totally custom projects, we can use only the framework and almost zero addons, then accasionnally plug on the standard addons on a very limited way, for example to handle invoicing or other common needs.
    The fact is there are plenty of framework improvements in the community addons. For example :Sentry integration, PG LargeObject, colorpicker widget, boolean switch widget. I believe it's a pity to keep most of these addons as separate addons. They are lost in the wild. They are not very visible, often poorly documented, and mainly they are not available by default.  Other possible improvements include a refactor or rewrite of the system of permissions, rôles, and groups (or a rename of groups as roles, what they really are since the beggining, and an implementation of real groups, in the common sense.). Another long lasting need: an alternative responsive web skin *by default*. Not as an addon!
    So as a summary the community whould publish the framework alone, without any addons except the base ones, as it is very useful for itself, then fork it, and enrich it with all the improvements already found in community addons, with a strict and documented way of selecting the relevant ones.

  • Second optional(?) thing : as more and more addons are proprietary, the community tries to compensate the holes of the community version with community addons. I think the second work to do is to select all the most useful ones, and merge these community addons into the standard addons of the community version (OCX or whatever name), so that they are available by default, and that the whole can finally be considered a final product by itself, and not a limited subproduct.

I would be ok at least with only the first point, so that the community can base its work on it by default. Then the second point is actually optional : instead of a unique consolidated set of addons, it could be done separately by many integrators as separate distributions targeting specific usecases or countries.  IMO the most important part is to keep a unique and improved underlying framework.

Christophe


Le 04/10/2016 à 16:09, Stefan Rijnhart a écrit :
<blockquote cite="mid:b71d6d05-ee71-ec4f-9590-43ce01624d77@opener.amsterdam" type="cite"> 
Dear OCA collaborators,

as a follow up to the lightning talk at the OCA codesprint today, let me
expand on my ideas.

The OCB project (https://github.com/oca/ocb) was created in a time when
Odoo itself was a lot more unstable and many core bug fixes needed to be
included in a production instance. It was a feast to collaborate with
the OCA community to share the effort and enjoy the benefit of each
other's fixes. Nowadays, there is a lot less interest in the project.
Not a lot of PRs are proposed, mainly I feel because Odoo itself is a
lot more stable, and smaller changes from the community are adopted more
quickly in the core project. Meanwhile on OCB, not a lot of reviews are
being posted either and some of the PRs that are still being proposed
are not valid against the policy of stability, as they would create
incompatibilities with Odoo (defined as: does a change allow the
creation of community modules that are compatible with OCB but not with
Odoo or the other way around).

It thus seems that the OCB project outlived its usefulness. My
suggestion would be to freeze the OCB project: no branch for 10 will be
created, and no more merges will take place on the existing branches. We
can still keep merging the upstream changes to the existing branches as
a form of limited support.

This would free up some resources for a replacement project. I would be
very interested for the OCA to host a version of Odoo that does allow
for more radical changes to the Odoo core. Currently, the ideas in the
community on what could be improved in the Odoo core just get lost,
because Odoo SA is not very open to them, and neither is OCB. I would
like to see what the community members come up with, and see if this
leads to a more vibrant project. Some restrictions would still apply of
course. If an improvement could be made in a separate addon, there would
be no reason to include it in the project.

As a part of the project, we would have to think about managing
dependencies, as it might be the case that community modules are created
that are only compatible with this new version (or worse, when
incompatibilities are introduced that break additional modules). We
would also have to think about clearly documenting the changes and
providing an upgrade path to later versions of the project.

Please share your thoughts on the topic.

Regards,
Stefan

-- 
Opener B.V. - Business solutions driven by open source collaboration

Stefan Rijnhart - Consultant/developer

mail: stefan@opener.am
tel: +31 (0) 20 3090 139
web: https://opener.am

_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe


_______________________________________________
Mailing-List: http://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: http://odoo-community.org/groups?unsubscribe




--
Lorenzo Battistini
Tel (CH): +41 91 210 23 40
Tel (IT): +39 011 198 25481

Reference