Clone the repository:
$ hg clone https://hg.tryton.org/tryton-env $ cd tryton-env
Make your modification. Submit your change for review:
$ curl -L -o ~/.local/bin/upload.py https://codereview.tryton.org/static/upload.py $ python ~/.local/bin/upload.py
Report an Issue
- Test your issue on the latest development version.
- Create an issue in our issue tracker.
- Set the affected components on the issue.
- Assign the issue to you and set the status to in-progress.
Submit a Change
- Follow the guidelines.
- Submit your change to our review tool using the upload.py script (see the help page).
- Make sure the review has the repository name at the start of the review title, and ensure the review description contains a reference to the issue (e.g.: issue1234).
- Add the review ID to the corresponding issue and mark it as testing.
- Ensure you did not break the tests by running them and add tests if necessary.
- Once accepted your review will be validated with a LGTM comment from a core developer
- Your change will then be committed and pushed by a core developer. The commit message will be the review subject (with repository name stripped) and the review description. The reference to the review (e.g.: review123456) will be automatically added to the commit message.
- Close the review once your change has been applied.
The Tryton Project has guidelines for both code and documentation.
- The Coding Guidelines should be followed for any review you submit.
There are several different places that Tryton documentation can be found. This is to make sure it is available in the right format, at the right time, for different use cases.
So to avoid duplication, and keep the documentation organised and maintainable there are several sets of guidelines:
Your contribution must meet the following requirements:
- By submitting a change, the contributor accepts the Developer Certificate of Origin.
- The contributor email must be a valid email address.
- The domain of the contributor email must not contain tryton.
- The username of a mercurial changeset must be in the form:
Nice to have, but not required
- The contributor name should be the real name of the natural person who submits the code.
- The contributor email should be linked to only one contributor name.
If the contributor has a significant amount of code, he can add himself to the COPYRIGHT file.
Core developers are people which have push access to the repositories. They are allowed to push small fixes without review. Bigger fixes need approval from other core developers.
In the case of disagreement, a consensus should be reached. As a last resort, the project leader (Cédric Krier) will make the decision.
Publish a Change
This part is only for core developers
$ hg commit -S --cwd tryton-env
Push to the remote server:
Sometimes the push is rejected because it creates a new head. This happens because your local repository is not up to date.
$ hg push ssh://firstname.lastname@example.org/tryton-env
We prefer rebase over merge because it creates a linear history:
$ hg pull --rebase
A fix will be back ported to older series by the maintainer on his own discretion after 1 week in the development branch. The decision is based on the importance of the bug, the availability of workaround and the feasibilities.
Those rules don't apply for security bugs which are applied at once to all affected series and followed by a release.