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.
regard
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.
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.
A forth way would be to create monorepo that groups a set of module about the same topic. They use a branch per series and they are branched all together (as it is a small set this can be manageable).
I made some tests and I think it can be managed with the convert extension.
For example we have the a module my_module in branch 6.0 and we want to copy in branch 7.0:
filemap:include my_module
branchmap:6.0 7.0
$ hg convert --filemap filemap --branchmap branchmap repo1 repo2
with repo1 and repo2 being clone of the same monorepo.
This copy the full history of 6.0 into the branch 7.0 but the branches will not share any root in common. But hg graft should still work.
If we want to have more people contributing we need to make it simpler. I will suggest:
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.
This does not explain how the branching/series are managed.
One branch per supported series.
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.
I do not think it is mangeable.
I thought that was the intent of the Third Party Modules - Tryton Discussion discuss category and some other existing discuss post.
IMHO what is clearly missing is a central catalog with updated metadata like
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.
This already exists: PyPI Framework :: Tryton
Why not? Which are the problems/issues that makes you think that will be unmanegable?
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.
I think 1 month and removing no migrated modules will be fine. For me if people don’t care to migrate the modules in such period is better to keep their modules in they own repo.
Another policy may be to keep them just for LTS. If we indicate that in the maintainers file, such modules can be directly removed for non LTS series and readded on new LTS series.
As far as modules can be removed or added based on demand it will be fine.
Then it is better to not manage such repository as there will be no module.
For example B2CK may have some but we will not manage to upgrade them in such short period.
More policy means more maintenance work which is the opposite of the goal.
I do think that will be an issue. The module will be removed for unsuported series and added latter if needed.
No, as we will just remove the not supported modules for the series.
So having a file to indicate the support of each module eases the maintenance.
So we loose the main point of using a VCS, the history.
I do not understand. What file are you talking?