Synchronization module as part of main release

Feature Ideas
1

Dear all

The synchronization[1] module allows the deployment of distributed Tryton instances, and to synchronize the information among them.

It is used in some GNU Health environments[2], and probably other Tryton installations, so it needs to be updated to the latest stable Tryton kernel.

Due to the importance of this functionality, it should be part of the main development[3], and kept up-to-date (it’s not compatible with Tryton 3.8) with the current Tryton release. Please let me know your thoughts. We’ll be happy to continue the development and maintenance for the synchronization functionality.

1.- http://hg.b2ck.com/tryton_synchronisation
2.- https://en.wikibooks.org/wiki/GNU_Health/Synchronization_Guide
3.- http://hg.tryton.org/

2

During the last days, I’ve been exchanging mails with Nicolas about it. This is to get a general idea on the interest of the community about the need of this functionality in Tryton in the medium and long term.

3

For me, the tryton_sycnhronisation is not generic enough to be part of Tryton. The reason is that it works mainly only for append only designed model.
Including in the base will lead people that it could be used for any Model of Tryton and so we will receive a lot of false positive issue reports.
And I don’t think the “importance” is a argument, we should take in consideration for inclusion. Tryton development is based on the quality and generality for the framework.
So for me, the development should stay as a side project as far as it is not completely generic.

Side note, as the original authors, B2CK will be happy to review and accept any contributions to it.

4

Hello

At this point, this is the situation:

  • GNU Health 2.8 installations using the synchro engine need to be able to update to GNU Health 3.0

  • GNU Health uses it extensively[1]

  • The project seems not to be of Tryton interest (it’s been almost 2 years without modifications)

  • You don’t want to make it part of Tryton

Then we will adopt it, host it in GNU Health, and let the GNU Health community keep it up-to-date and maintain it.

Bests

1.- http://www.iweee.org/2015-las_palmas/presentations/files/Nicoe-2-IWEEE2015.pdf

5

I don’t understand the logic to make an aggressive fork without even trying to contribute to the project. This is a sad news.
But it is under GPL-3 so anyone is free to fork it if he wants, I will just request you to not use the same package name (and even not the same module names) to avoid confusion for users.

6

@meanmicio from the two quotes above I don’t understand how you got to this conclusion.

All I can see is that it will be needed to generalize the module in order for it to be included in the core of tryton.

In my opinion, the syncronization seems like a great feature too.

Maybe what is not clear is what kind of things @ced thinks should be generalized.

Maybe that’s something that can be worked in this topic so we could all contribute and the whole comunity can benefit.

1 Like
7

Hi Karla !
@kstenger Here is the rest of the quote :

I agree that the synchro engine should be part of Tryton, and actually,I always saw it that way. But I can not force anyone. At the same time, I have to make sure the GNU Health community has the synchronization engine updated, so they can update GNU Health. I can’t permit any dependency issue that could jeopardize the project.

8

I’d like to know more about what has to be done to generalize this module @ced

9

But I don’t think it can be generalized. Indeed synchronisation based on SQL database is almost impossible without limiting it for me. But if someone has a great idea to solve this problem, it will be welcomed.

10

So I don’t see why you don’t contribute to the project instead of forking. It will be a more constructive behaviour.

11

Because, as you said, you don’t consider it a Tryton project, but a B2CK project. Major difference.

12

So go fork all your dependencies…

13

GNU Health can be keep the upgrade path perfectly with its dependencies, except for the synchronization engine.

14

It is sad to see someone like you behave like a customer against a free software project. I though you have understood that it is collaboration and contribution that makes software progress.

15

Cedric,

You have crossed the limits, and enough is enough. You have taken the discussion to a personal level, manipulating the information, making false accusations, and attacking me publicly. Not only is unfair, but it constitutes a clear violation of the Code of Conduct[1]

I admit making a mistake: recommending you for the task of the synchro engine. In return we get from you an unmaintained, obsolete package in a private company repository, snakeoil and personal attacks … Fortunately, life normally gives us a second chance to avoid making the same mistake in the future.

It’s quite sad, and I have put time to take the decision, but this energy draining, toxic relationship takes us nowhere, and it only harms our respective communities. So this is all from me.

Here remains the conversation logs and anyone can take their own conclusions.

PS: Free Software takes much more than coding.

Enjoy life and I wish you the best.

1.- https://en.wikibooks.org/wiki/GNU_Health/Code_of_Conduct

1 Like