How to Develop
Clone the repository:
$ hg clone https://hg.tryton.org/trytond $ cd trytond
Make your modification. Submit your change:
$ curl -L -o ~/.local/bin/upload.py https://codereview.tryton.org/static/upload.py $ python ~/.local/bin/upload.py --oauth2
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 coding guidelines.
- Submit your change to our review tool using one of the methods listed below.
- 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).
- 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.
There are two options to upload changes:
There is a mercurial extension, hgreview which simplifies the workflow.
Install the extension:
Edit the file to include:
$ pip install hgreview $ hg config -e -l
[extensions] hgreview = [review] server = https://codereview.tryton.org oauth2 = True send_email = True
You can then upload your change (do not commit before doing this):
For non-trunk fixes append the series number to the repository name.
$ hg review -m "repository_name: Improve things a lot"
Publish a Change
This part is only for core developers
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/trytond
We prefer rebase over merge because it creates a linear history:
$ hg pull --rebase
$ hg commit -S --cwd tryton-env
The Tryton Project strongly recommends the following guidelines.
Code style, in general, follows PEP 8:
- Use 4 spaces for indentation.
- Avoid the usage of from M import *.
- If unsure about PEP 8 conformity use pep8 to check the code (with option ignore=E123,E124,E126,E128).
- Breaking lines:
- Use 4 spaces per bracket pair.
- Prefer parenthesis over backslash.
- Use 4 spaces for indentation.
- No 80 columns limitation.
- Opening tag on single line or one attribute per line.
- Use doc-strings and comments in your code.
- Never pass keyword arguments as positional arguments when calling a method.
- In the very beginning (right under the doc-string) of a method definition, define all pool objects that will be used (pool.get(...)).
Naming of modules, classes, variables
- A name should be as descriptive and as short as possible.
- Avoid unnecessary duplication of names.
- Naming structure of a model or module must follow these rules:
- First part of the name is the general function of the module or model,
- after this come the less general parts of the name (i.e. the more specific name parts) for the module or model
- If you are unsure with naming, please ask first on the #tryton channel
- For modules and method names use an underscore to separate the parts of name.
- For naming classes use CamelCase.
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.
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.