Contributors mailing list archives
Re: The future of OCBby
Kidding but Stefan I was about to suggest similar things regards a more divergent branch. Was literally waiting till end of next sprint when we start serious v10 work.
We will commit serious resources to such an effort.
That's just on a cursory v10 evaluation.
AlexandreWe should think of a name if we're going to to move in that direction.OCX ?
--2016-10-04 16:53 GMT+02:00 Pedro M. Baeza (Tecnativa) <firstname.lastname@example.org>: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.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: email@example.com tel: +31 (0) 20 3090 139 web: https://opener.am