Contributors mailing list archives
Re: The future of OCBby
You're welcome Stefan!That said what about having a real mother f.. DMS being part of this OCX ;)2016-10-08 1:08 GMT+02:00 Stefan Rijnhart <firstname.lastname@example.org>:
Thank you, Houssine. Your clarification is very much along the lines of what I had in mind, rather than choosing a diverging path from Odoo at this point.On October 7, 2016 2:53:18 PM GMT+02:00, Houssine BAKKALI <email@example.com> wrote:I like the idea of Stefan so let's begin with is not so simple idea and see what happen!The aim is to have a branch depending on the Odoo version on which the enhancing PRs would be merged as it was done for OCB. This looks more like a OCE(Odoo Community Edition) that allows the community to make use of monkey addons patch due to the core limitation.I think that some of you are mislead.The point of having an OCX branch instead of OCB is too free the resources that was maintening the OCB for this new project that if if it's technicallay a fork has not this purpose.This could also be a playground for more experimental things on the framework, the webiste or in the web ui.OCA needs Odoo and Odoo needs OCA, in top of that OCA alreadt lacks contributors for code review so it's a bit unrealistic to think about a full maintained Odoo detached from the head.2016-10-07 14:23 GMT+02:00 Michael Delvoye <firstname.lastname@example.org>:HiI think like jean SebastienMaybe oca needs to become an Erp free and not depending on Odoo versions
Le 7 oct. 2016 à 11:08, Jean Sébastien HEDERER ASPerience <email@example.com> a écrit :
I'd like to say that if most OCA members want to cut links between "Odoo official core" and "Odoo OCA core" in order to create a new way for all, I'm interested in participating. I do not participate for the moment because I see no value to run after Odoo SA versions from year to year, porting modules version after version, keeping some, letting others unported because of lack of time. If OCA wants to create value, it can only be with a stable core version on which we will be able to add enterprise functionalities, not shareholders functionalities.
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: firstname.lastname@example.org
Sent from my Android device with K-9 Mail. Please excuse my brevity.