For me history is not so important as having some code that is shared between a group of persons and having a way to report issues with such modules (issue tracker) and also a way to contribute so such modules (merge request).
The history of the features added to a module can be just managed into a changelog entry.
The main point is that I won’t expect that people will contribute to latest supported series (for that we have offical modules) so they just contribute to the required branch and then changes will be ported to new braches if there is enought interest.
In this message I talked about people that could be interested by a non official module repository (I don’t exactly like the term “non official” but let’s not get lost on this kind of nitpicking).
I think that we should ear more from people writing modules that are not commiters to Tryton because let’s face it @pokoli, @ced and me we are not people that will use this repository the most.
For example the people maintaining the module I mentioned in my message:
Or from people like @albert, @udono, @jgras, @timitos or even @maxx
Or from people used to the way others are organizing (such as the OCA), presumably @jssuzanne maybe @SISalp.
Maybe even people (@meanmicio) working on GNU Health (but I don’t think it’s a good fit as it’s a GNU project and they are linked to savannah)
What would you gain from this repository? How could it help you? What would make you thinking about switching to this repository instead of github / gitlab ?
After careful though, for me the solution is to create a sub-group on Heptapod in which we create repositories that contain one or many extra modules. We assign one or many maintainers to those repositories. They deal with the branching when they want (we just enforce to use the same branch names as tryton repository).
We provide at the creation of the repository a simple template with a .gitlab-ci.yml that works well and they create modules using the cookie-cutter template (using the repository name as prefix).
I have one use case which is to have a repository which contain backport to older series of new modules. At B2CK we already have some of those module that we could share.
So now I think as @nicoe said, we need to collect a list of modules or group of modules that people would like to add to these repositories.
Hello my contribution to the discussion is more than a repository “No offcial” should be a repository for countries that use tryton with the objective that there are customized modules to the structure or management of such countries for example when the accounting is adapted to each country and so on, also as there will be a review of the code and operation of each module as it would be good to categorize them so that they do not go up to the core, but are useful to other users for something in particular and would be very good to see the contributions that people make to the interface that customize them and so as to have an interface a little more dynamic.
Indeed. As a 0-effort resource the PyPI marker is invaluable. There is still some aditional value one would find in a dedicated catalog (just see djangopackages), but this is far from zero-effort.
I imagine I could benefit from a repository template that would ease the task of creating, testing and publishing a module, and also keeping it updated, even if it was tailoerd for heptapod. I may be imagining the cookiecutter module.
But, once I am used to git + github/gitlab + an arbitrary CI that is mainstream in my organization, and I already use that for other non-tryton or non-python software components, I imagine nothing would make me switch to heptapod.
I believe that if we could have a central repository of contrib (I think non-official name does not suite what we want to said to the community) modules would be great. Perhaps, some of the modules would be contrib all their life, but would be great to have it also. There are a lot of modules of tryton out there that we don’t know where are, or sometimes do the same thing, but with few differences.
I know the Drupal project (and it’s similar to Tryton as it’s Sotware Libre and Community Software) and they have a lot of contrib modules upload it by it’s community, and their repositories are under the drupal.org git repository, so the workflow to work with those modules are the same that the workflow of the core project. The community does not have to look for over the internet to know where are other modules other than the main proyect.
For other hand, the developers gain the idea how to work with the same tools of the core proyect and probably, some day would start to contrib to the main tickets.
My POV is similar to exposed by @Dan. I have mixed opinions depending on which hat I put on of.
as a Tryton community user, it would be great to have a place in tryton heptapod where to find non-official modules with certain quality assured.
as a Tryton developer, it would be great to have a place in tryton heptapod where to create, test and publish non-official modules based on some cookiecutter that simplifies the process.
but as organization, I don’t see a good reason to change my CVS, host, CI, release process, etc. with tryton heptapod. Note that we moved from bitbucket → gitlab.com → gitlab self-hosted in last 4 or 5 years due to provider decisions and by now I don’t want to change again.
Despite this I would like to share my modules and make them visible in that space.
So for companies in same situation as us, I would propose the creation of a single repository with module index/directory where we can add (with MR lifecycle) a brief description and link to the module source code.
The modules added should have quality requirements, as LTS version supported, CI configured, … in order the MR will be accepted.
This will be compatible with non-official modules published directly in heptapod.
About the management of the published repositories in heptapod, I don’t see neither a single repository nor force to foundation lifecycle. I agree with @cedk that should be a new group/subgroup (and probably with subgroups) and different maintainers (the publishers maybe?) with the aim the modules will be almost self-managed by publishers.
So after one week of asking some old timers in the community their opinion we can see that people are not really interested in such a repository / discussion.
Thankfully @Dan and @sergyo gave their opinion which I would summarize as “It would be nice but we have already made a choice and we won’t change”.
About the lifecycle of the projects in such a repository, they both stated that having to be forced to follow the foundation would be a chore and not something they would like to do. They also preferred not to mix their code with the production of others.
So indeed, it’s a nice idea but it comes probably too late as a lot of people already have their workflow set up. But if we decide to do it anyway, we should aim for multiple repositories benefiting from the CI infrastructure. Imposing the pace of our releases is also a no go.
Nevertheless I think we should go on with the idea of a contrib package repository. I could gain momentum and replace the already existing modules doing all the same thing, it could also hold modules which do not meet the quality requirement need to be included.
This is a bit controversial but I wonder if at some point we might move modules from the official repo to contrib (google_maps, all the accounting country localisation, …). Tryton would provide the means and the hooks in the code for those to do their work but the project would let the people do their thing for their localization as they see fit (thanks to @HLSC for the idea but I take the blame for the controversial part ).
So my proposal would be:
a subgroup contrib
there shouldn’t be rules regarding the release management because it seems that people don’t want this burden
one repository per module.
inside contrib we would welcome potentially other subgroups if people want to set their own rules (regarding the release management or because they’re working on a verticalisation and want a coherent set of modules in the same repository) (from @sergyo and @ced ideas)
@lukio and @Dan also pointed to the usefulness of a website grouping all the existing packages à la djangopackage or the drupal equivalent. Which reminded me of the idea we had 10 years ago of creating a Tryton Package Index. I am not sure it’s needed since we have the third party module category in the forum where people can discuss the modules that are hosted in contrib. So I would put that on the bottom of my todo list but of course anybody that would like to tackle this task is welcome to do so .
I see a contradiction here. People can have a rule to have more than one module per repository.
Indeed the best is probably to provide a cookiecutter template for a contrib repository which provide the same kind of testing as in tryton repository. From there it is possible to have a single tryton module or many.
The rule only apply for the level right below contrib in my mind.
So as long as they have this rule in their own subgroup it’s fine by me.
contrib
my_incredible_module: one module doing incredible things but I don’t care about Tryton release I update when I want.
backports : a subgroup working on backports, obviously there is no need to follow each release (it can be discussed but it’s just an example)
quality
whatever
gnu_health: a subgroup working on GNU Health related modules (just an example again)
modules: all the modules in one repo
tools: tools useful for GNU Health.
accounting_localizations: a subgroup following the Tryton releases
here be dragons … I don’t know the layout it should follow. Probably one repo per country maybe one subgroup, I really don’t know. From my point of view it’s up to them to come with their preferred organisation.
I do not see any point for such rule. Indeed I think it will be better that all repositories have the same structure even if they contain only one module.
OK we can drop that rule. But I still think that we shouldn’t impose the release cycle of Tryton. As @Dans and @sergyo said it would be a burden for them and this subgroup is made for those people to contribute to Tryton so I think such a rule would be counter productive.
About the content of the repository created, of course having the same structure would be nice but quite frankly it’s not something that bothers me. Of course we should monitor every once in a while that people don’t mess with the CI to do stupid things but apart from that the content of the repository is left up to its author.
I do think that having the same structure everywhere will be an important rule to get this contrib sub-project working. Because it will provide a common way to contribute to any of the repository and this will lower the learning curve.
I do not think because why would someone rewrite a full gitlab-ci.yml when there is already one provided from template. And adding a module can also be done by template. So it will just be a matter of running 2 cookiecutter (and the first one will be probably done by project owners).
If we go this way we need to have a clear criteria about what modules should be part of contrib and what modules should be part of standard.
I do not see any reason to remove all accounting localization modules from the official modules and move them to a separate repository.
Also if I want to create a new module, which will be the criteria to add it as part of contrib or as part of official module. We also need to think if we want to allow the transition from a contrib to official.
If you mean backporting official modules, I do not see any reason to have it in a separate repository but just problems. For example if a module released on 6.4 is backported to 6.0 on contrib, users from 6.0 series will report issues on the contrib module instead on the official one.
I will prefer to have backports as part of official modules. As far as we just backport new modules, nothing will break (just people requiring it will install them) and LTS users will benefit for new features which is always interesting.
Then why I should care about adding in an external repository if I can add them in my own repository and include it on the third party modules category?
Sorry I do not see any sentence here so I’m unable to understand it.
).
.