1. Mailing Lists
  2. Contributors
  3. Re: The future of oca/bank-payment

Contributors mailing list archives

contributors@odoo-community.org

Browse archives

Re: The future of oca/bank-payment

Re: The future of oca/bank-payment

Avatar

Re: The future of oca/bank-payment

by
DIXMIT Consulting SLU, Enric Tobella Alomar
- 18/04/2025 18:48:38
Hi Stéphane and everyone,

I understand that creating a fork is not the best outcome, but it seems inevitable right now. If we need to create it, I would call it experimental. As I explained several times, the native use of this fields is not the use that you are proposing (you can check on Odoos commits to see that it just a field for help on the creation of payments, nothing else). Odoo's approach is completly different in this topic and we are trying to enforce our system in something different. Also, using the word native is a way of saying that the original work is not "native". Obviously, this is not correct and you are enforcing an opinionated option as the "native". Also, we have no confirmation on this topic from Odoo (and I think they will never give an answer on this topic). For these reasons, I would never call it native, as Graeme said, calling it experimental seems a good approach. In any case, my vote is to avoid the creation of this fork. I understand that this might be rude, but you are trying to enforce a specific way of doing without taking care of PSC comments. Reviews were added on this PRs and we received no answers, we raised concerns about it and you couldn't give any compromises. In my opinion, this a rude way to act on a community environment.

Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health. But, IMO, we delivered comments and opinions and we were ignored everytime. Even so, in the explanation of how the meeting was, it was something like: Some people opinons, but it is just opinions... Alexis thinks that his code is better, so his code is better(without proofs)... However, even Alexis confesed that he was not doing a proper work as maintainer of the tool. Sorry if some people thinks I am too direct or rude, but sometimes people need to be clear and expose their fears and concerns.

Also, some PSC offered their help (Pedro and myself for example) in order to get a a middle solution, but we received no answer on that again. 

Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from Alexis side as he refused to get a middle solution no matter the comments or problems raised from the other side. IMO, merging Tecnativa's PRs was a good way to proceed, as Alexis was not giving any options to get a common ground and we have been waiting several months for this.

Personally, I have been in similar situations where two people offered different solutions for the same problem and both parties tried to converge. In this case, only one of them proposed things to converge. The other one, made a fork and tried to enforce their opinion no matter what (even loosing work from other people...)

Kind regards,

El vie, 18 abr 2025 a las 17:43, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:
Hi everyone,

As we are Friday 18th, have we obtained more information from Odoo about their intentions with these fields?

Pedro, I find it really rude that you closed PRs without waiting for the conclusion of this conversation.

Anyway, since this is done, I conclude that the decision is taken, and it is not possible to converge for 18.

I am disappointed and I see that as a kind of failure for our community that a fork has to happen, but this is the only way forward I see. 

The only possible solution that our tooling supports is creating modules with new names. Since these modules will contain models with identical names, we need to declare them conflicting with the existing ones in their manifests.

A new repo is not strictly necessary but seems useful to reduce confusion. As I re-read the thread, there was agreement on that.

I don't have a strong opinion on the name of the new repo. Alexis' proposal of bank-payment-native is better that anything else I can think of so far. Let's open the PR on repo-maintainer-conf. We can still adapt the name if a better one emerges.

Could the READMEs of each repo (and if possible each addons) reference each other so users can make informed decisions and encourage future convergence?

Ah, one last thing. I'm also saddened by the ad-hominem attacks in this thread. This is definitely not what we want in a thriving community. Maintaining open source projects is not easy, and if perfect maintainers exist I don't know them.

To conclude, let's recognize that if convergence is not possible, exploring different approaches is also healthy, and OCA can provide room for that.

Wishing you a nice weekend,

-Stéphane


On Wed, Apr 16, 2025 at 11:06 AM Graeme Gellatly <notifications@odoo-community.org> wrote:
Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests.  Although maybe there is a better way we can do that.

merges:
    - origin $ODOO_VERSION
    # Can't merge 1439 at the moment because of this
    # test-requirements.txt commit:
    # befd64bd07aaa293026b648bc06494d6f1b466fc
    #- origin refs/pull/1438/head # 'account_payment_mode'
    #- origin refs/pull/1439/head # 'account_payment_partner'
    #- origin refs/pull/1440/head # 'account_payment_order'

On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:

- The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.
- The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.
- It contains a lot of datamodel changes apart from the main question, which are the same problematic.

And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...

I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.

Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.

Regards.

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

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

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



--
Enric Tobella Alomar
CEO & Founder

Reference