1. Mailing Lists
  2. Contributors
  3. Re: The future of OCB

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: The future of OCB

Re: The future of OCB

Avatar

Re: The future of OCB

by
Camptocamp France SAS, Alexandre Fayolle
- 04/10/2016 17:30:56
We should think of a name if we're going to to move in that direction.

OCX ?

--
Alexandre

2016-10-04 16:53 GMT+02:00 Pedro M. Baeza (Tecnativa) <pedro.baeza@tecnativa.com>:
I think we shouldn't deprecate OCB, as it still has an importance in the community environment.

As you have said, there are less bugs and the stability is very good (kudos to Odoo!), but there's still some nasty bugs that are not handled and that prevent the full use of Odoo. You can check for example my last 2 PRs about a JS error that doesn't allow to make use of a legal Odoo option: https://github.com/OCA/OCB/pull/548 and https://github.com/OCA/OCB/pull/547. There's not too much hope to get this bug fixed, and it's no impact in official code (they're not using this option), so I think this branch is still valuable even for a few patches. The maintenance of this branch is very low: an automatic synchronization that is hosted by Therp that we can transfer to OCA, and sometimes some conflict resolution that has to be done manually. You can see in this page that there's not too many problems.

So for me it's clear that we should keep it.

But that can be complementary to other projects like the one you propose. Anyway, this is technically a fork, and this means that we need a lot of work to be maintained, which can be a real problem nowadays. I see other obscure points like if this is going to be a frozen version or if you plan to merge upstream changes. Both possibilities are not ideally, because the first one requires a separated bug-fixing, and the second one makes very difficult the conflict resolution as the code base can differ a lot. I think most of the things we can do in separate modules, and if you're thinking about some nasty hacks requiring monkey-patching and so on, now the situation improves a lot thanks to the inheritability of the base model, that avoids all the current OCA modules known hacks.

Taking all of this into account, I would say no for this second proposal, unless you tell me something that I'm missing right now.

Regards.

2016-10-04 16:09 GMT+02:00 Stefan Rijnhart <stefan@opener.amsterdam>:
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




--
Alexandre Fayolle
Chef de Projet
Tel : + 33 (0)4 58 48 20 30

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac Cedex
http://www.camptocamp.com

Reference