TL;DR
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.
warning If it is a security issue, be careful to correctly set the type to security. This way, the issue will only be visible to the security team until its release.

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.
warning If it is a security issue, be careful to mark the review as protected.

There are two options to upload changes:

Script

Download upload.py and read its help page.

Mercurial Extension

There is a mercurial extension, hgreview which simplifies the workflow.

Install the extension:

$ pip install hgreview
$ hg config -e -l
Edit the file to include:
[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):

$ hg review -m "repository_name: Improve things a lot"
For non-trunk fixes append the series number to the repository name.

Publish a Change

This part is only for core developers

Push to the remote server:

$ hg push ssh://hg@hg.tryton.org/trytond
Sometimes the push is rejected because it creates a new head. This happens because your local repository is not up to date.
We prefer rebase over merge because it creates a linear history:
$ hg pull --rebase

warning Always keep the environment repository up to date with all the subrepos:

$ hg commit -S --cwd tryton-env

Coding Guidelines

The Tryton Project strongly recommends the following guidelines.

Code Style

Python

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.

XML

  • Use 4 spaces for indentation.
  • No 80 columns limitation.
  • Opening tag on single line or one attribute per line.

Best Practices

  • 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.

Requirements

Your contribution must meet the following requirements:

Must

  • 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:
    Name <email>

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.

Rules

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.

Backporting

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.