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?
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.
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.
If we want to have more people contributing we need to make it simpler. I will suggest:
One single repository with all modules
One branch per supported series
No development version, we just develop on released series
Contributions are welcome to any series, with the condition that latest stable series is always updated with all features
Same CI as tryton is used, contributions will be rejected if CI is failing
Only modules that have interest for more than one contribution/integration will be accepted. One should raise an issue asking for interest from other members before adding the module to the repository. Such members should be named into a file in the repository and they will be responsible for maintaining such modules.
Also we should have some way to remove unmaintained modules. As people need some time to migrate to released series, i think that modules which do not support any of the last two stable releases should be removed. That gives 1 year of time to migrate to newer series.
It may be interesting to automate the release of modules to pypi and even generate a docker image with all modules. But I think we can start without it and add it latter if there is enought interest.
When a new release is added all modules version will be bumped on a draft MR, modules will failing test will be removed unless the maintainers fix them. Maybe we may include some period of one or two weeks to fix such modules.
IMHO what is clearly missing is a central catalog with updated metadata like
is this 3rd party component a module?
link to documentation
link to source code
link to issue tracker
tryton versions compatibility
last activity date
last release date
pypi download stats
cvs platform stats (github stars and whatnot)
functional area (e.g. stock, account, sales, server…)
That is: something in the mood of https://djangopackages.org/ (when in doubt about something, just ask youserlves “what would django do?”)
If it was a repo in heptapod (instead of a DB for a website), it should be a repo solely containing links where to fetch this metadata, and its CI be a process refreshing this metadata and publishing it to a website. This is something the Tryton Foundation could maintain.
As a creator of Tryton integrations and modules: I am not moving their development to heptapod. Essentially, I am not adopting any tool I hadn’t adopted beforehand nor modifying my organization’s workflow.
Suffice to say, abiding by GPLv3 you can go ahead and vendor my modules/integrations anywhere that pleases you, I just think that would be an unacceptable burden for the Tryton Foundation.
Either you setup a short period to update or remove and you will have almost no module.
Either you wait and you will never merge.
Also I will expect that people will care only for the series they are running so some will stay on LTS other on some random series etc. So the management proposal must support upgrade of each module individually.