Contributing to the code development and reporting/fixing bugs

Contributing to the code development and reporting/fixing bugs#

General coding rules#

  • Write in a concise and precise manner

  • Document your code

  • Avoid using too specific packages to maintain the CIF in a state as generic as possible

  • Include tutorials for new features

  • Write in English only in your codes (including comments and variable names)

  • Follow the general PEP8 and affiliated community standards

Reporting bugs or cleaning/reviewing the code#

Despite efforts by developers to maintain the code stable, bugs can remain undetected and/or can appear only in specific applications of the CIF. Similarly, the code is writen in a manner as clean as possible, but improvements are always possible.

In both cases, you are encouraged to report such issues in the GitLab issue tracker. A GitLab account on gitlab.in2p3.fr is necessary to do so. If you don’t have one, you can register for free or contact help@community-inversion.eu. If for some reason you prefer not to create an account, please report issues directly to that address.

When fixing bugs yourself, you are encouraged to create a new dedicated branch locally.

cd /where/you/have/the/sources
git checkout -b [name_of_your_new_branch]

Fix and improve the code in the way you consider relevant, test it and commit your changes. Once pushed to the GitLab server, please submit a merge request here. Otherwise, consider generating a git patch and sending it to help@community-inversion.eu.

To generate a patch from the branch my_bug_fix_branch to the main branch master, use the following commands:

git checkout master
git pull origin master
git format-patch my_bug_fix_branch -o <target directory>

Implementing new features in the CIF#

New features are welcome to the CIF. However, before starting new developments, make sure than your specific feature is not already implemented as a specific application of more general capabilities of the system. Feel free to contact the development team. Please propose new features in the GitLab issue tracker directly. It allows the rest of the developers to follow what you are doing and possibly to propose solutions to your needs.

New features to implement in the CIF should not be application specific. They need to follow the general philosophy of the CIF of avoiding redundant developments and coding in the most possible general way.

Proposing significant changes#

Some changes are hard to reverse once merged, or force reviewers to reason about parts of the system they don’t own — a change to a plugin interface, anything altering numerical results or adjoint/tangent-linear consistency, a new heavy dependency, or a change to the user-facing config/YAML contract, for instance. One-way-door / numerics / interface / cross-cutting changes like these need an RFC (Request for Comments) before code: a short design document reviewed before significant code is written, so the reasoning is externalised while the design is still cheap to change.

A decision that has already been made elsewhere (in a merge request, a meeting, or historically) and is load-bearing enough that a future maintainer would need the reasoning gets an ADR (Architecture Decision Record) instead — a short record, born Accepted, with no pre-implementation review gate. An accepted RFC already serves as the permanent decision record; we do not write a separate ADR for it.

Everything else (bug fixes, new plugins that conform to an existing interface, docs, tests, internal refactors) is just a normal merge request as described above.

See CIF Design Decisions — RFC & ADR for the full process, both templates, and the index of past decisions.

Testing your code#

Testing is an integral part of the coding process. No branch should be merged to the main branch without proper testing. The GitLab main repository is designed to run default tests whenever a branch is pushed. These default tests are designed to detect unexpected side effects of a given development. Any branch not passing these default tests will not be allowed to merge to the master branch.

However, these default tests are only simple tests and do not encompass all possible use of the system. Therefore, merging a branch should not be requested without a proper testing of the newly developed feature. Developers are encouraged to test their own developments on their systems and provide necessary data and configuration files to the core development team to help reviewing and validating new codes.

The tests are managed through pytest (see for example here): more information on how to check the default tests, add tests, run tests are provided in tutorials.