Add in Heptapod a location to push the nonofficial module

The goal is to have a place where anyone can push a tryton module.

The module is not maintained by tryton and offers no guarantee of proper functioning. It allows integrators to share their development.

In my opinion, a series of rules must be defined in order to ensure maximum quality.

  • License.?
  • 1 single repository / 1 repository per module ?
  • CI ?
  • Release policy ?
  • Documentation ?
  • 1 branch per version ?

regard

1 Like

I had been thinking on this idea for a while but I’m not sure if its really a good idea. First tought that we should answer: As anyone is able to contribute to Tryton why we should have non oficial modules?

Also I think we need to have some trust for people adding repositories there. Otherwise we will end up by having a lot of unmaintained modules.

Another tought is: Who will maintain such repositories? If it will be maintained by one person it is better to have it in a personal repository. That goes to another question: Which modules do you want to add to this unoffical? What prevents you to add them to the oficial modules?

Yeah we discussed this with CĂ©dric a few days ago too.

Indeed we already have the Third Party Modules category but it’s not exactly a success.

Because sometimes people do modules for things that will never go into Tryton (eg: the recent discussions about the invoice lines acting as the sale line wrt the product). There is apparently 4 different modules reimplementing this behaviour out there. Of course my first reaction is that authors of those modules should collaborate either on github, gitlab or whatever. But then I realize that if we can attract those authors to heptapod then there will be less frictions for them to contribute on Tryton itself as they will already know the workflow. But I am not sure it will work because the step from “unofficial” modules to “official” modules in term of expectations will be quite high.

So from my point of view what is important is not what those modules do as much as who are the people doing it. If we can attract those people on the same platform as the one we use then we might gain some new contributors.

My point of view is that we wouldn’t be responsible at all about what is in this repo, so why bother maintaining it? It’s their author duty to do that.

As usual I am on the more lenient side for this kind of things: we should test if it works and if not we close the repository it will just be a return to the current situation. @ced was more in line with your position IIRC.

1 Like

It will be good if we can find a way to avoid reinventing the wheel.

I tought that having a clear way to do the transition to oficial will be a good idea to share (and release) modules in beta status for testing while they do not reach the requirements for beeing oficial. The apache incubator projects is an example of such workflow. For example, we may contribute the WooCommerce connector for Tryton as incubator module and there if enought interest on it finish to make it an official module. Also this will allow some people to start a module and allow others work to make it become official.

I think the may benefit of unoffical module is to publishing them on some place so anyone can contribute it. So we should care at least to remove unmaintanined modules or to not release them. So we must carefully think on which release proces to use and when to deprecate such modules.

I do not dislike the idea but we should define the rules for everyone and find if it is really interest on it. I guess a lot of people will say thats interesting but less will contribute, so we need to give contributors some benefit to attract them.

From my pov the Tryton project is only providing a place where people can collaborate and nothing else.

If the authors want to make a release they do so but we, as a project, won’t do any release of modules or tools in this repository. That’s also why I don’t think the project should remove unmaintained modules … it’s up to their author to decide if the module / tool is still relevant or not.

Of course it must be free-software license. And probably to avoid license compatibility nightmare we should enforce only GPL-3 modules.

1 repository per module will require the admin to create and configure it. So it is an extra load for the admin. But it will allow to branch to new series whenever the developer wants.

1 mono-repository will simplify the job for the admin. But it will be difficult to manage series except if each new branch start empty and modules are copied when updated. This will loose the history. It would be good to have insight from Mercurial experts.

another way would be to have a branch per module (and series). It will be more difficult to see all the modules but the history of each module will be preserved.

I think we could provide the CI, it is always good. In case of monorepository we can almost duplicate the configuration from the standard repository.
But I do not think we will be able to support development series but I do not think it should be the case.

We may allow to publish on the Hetpapod registry based on tag. This will allow people who wants to deploy such modules to use the registry and avoid others to install by mistakes.

We could create a readthedoc project and add each module but this will add some extra work for the admin because webhook must be registered.

I’m in favor of having one repo per module. This allows separate management as well as separate (and lightwight) CI. Additionally separate credentials can be used per repo, contributing to the need-to-know and least-privileges principles.

This would be even worse then having separate repos per module: Admins would not only need to clone a huge repo, but also check out a specific branch. And even worse: getting an overview which modules are available is de-facto impossible.

2 Likes