Since a long time, we are looking for the right tools to develop Tryton. Our current solution is commonly accepted to not be the best but more a lack of better. I think the problem is that we search for tools that works better with our current workflow instead of rethinking the all workflow. So I will start by describing my ideal contribution workflow without caring about the tools. The workflow should work for a core developer but also for a casual contributor:
- Review (iterate from 2)
- Publish (core developer)
How can we achieve such simple workflow.
The first point is that we should use a single repository which contains the server, the clients and the modules. It should be ready to use/develop. It should be possible to migrate the existing repositories into a single one while keeping the all history and tags. (I have discussed with the guys from Octobus about our case).
There are few points that should be fixed prior the migration:
We need to find a solution to run
tox only for the modules which were changed. But also that
tox installed the Tryton’s dependencies from the current clone (no more trydevpi.tryton.org). This could be done with a script in
command_pre that parse recursively
tryton.cfg for dependencies and install them (but without failing if they can not be found. E.g. running test from installed package).
There is also the
.drone.yml which is the same for all repositories except for
sao but they could probably be merged with two entries in
We will have to tag each release with a prefix. E.g.:
But I do not think it is a major problem.
As all changes will go into the same history, it will be needed to prefix the commit by the name of impacted module. E.g.:
account: Update tax code lines when updating chart from template.
This may be an inconvenient for module having long name, so we should probably be not too strict or not do it at all (it is possible to get the history only for a directory).
We will keep the build of each module documentation separated. For that the hook that trigger the build should look at the changed files and trigger the right rtd project (using a configuration field module->rtd ID). The rtd project should be configured to point to a
conf.py file inside its doc directory (the file could just be empty but it is necessary to define where is the directory in the mono-repository).
To ease the push process, it is easier to be allowed to push on the cloned repository. We could setup a repository open to all which keeps changesets as draft. To organize a little bit this open repository, the evolution extension and its topic sidekick can be used to follow development of a feature (aka topic).
Core developers will be in charge to push reviewed topic to the official repository and thus makes the changesets public. Every changes should land first on the open repository before being published to the official repository, this ensures a one direction synchronization.
The open repository will use the ssh keys stored on the bug-tracker profile of the user. This will prevent spam and vandalism.
The drone instance could be plugged to this open repository and so each changes could be fully tested before being published.
Some cleaning task will be needed to remove topic that were refused.
The bug tracker hook could also be configured on this open repository. It should just post comment on the linked issue but not close it (this could be based on the phase of the changeset: public=close, draft=testing).
As changesets will be committed and pushed to an open repository, it will not more be practical to use Rietveld for code review because it works better as pre-commit review.