Any issues with ECMWF software should continue to be reported either by email to Software.Software@ecmwf.int or in the Software Support page at ECMWF. The issue management system on GitHub should only be used for issues around code contributions to the packages. In doubt please contact ECMWF Software Support.


The GitHub ECMWF space

ECMWF tries to provide a set-up which allows easy co-operations with the wider community:

  • Allow users to fork code repositories & adopt the codes to their needs; but also allow continuous pulling of changes at their convenience. These changes can be contributed through pull requests.
  • Various test & build services can be automatically linked to the repositories to ensure CI testing and automatic builds.


https://github.com/ecmwf

Code contributions to ECMWF software

Code contributions on ECMWF GitHub space should follow the standard fork-based contribution model on GitHub, which ends with opening of a pull request. Any contribution should follow these steps:

  1. Fork the master branch of the targeted package from GitHub to your own GitHub space
  2. Clone your fork locally
  3. Make the necessary code changes & add and run tests to ensure the new codes works as intended
  4. Push changes back to fork on GitHub
  5. Create a pull request (PR) back to ECMWF:
    1. Describe the motivation of the change and impact on code
    2. Accept the ECMWF Contributors License Agreement (CLA - see below for more information)
    3. Make sure that all requirements of the PR are addressed
  6. As soon as all conditions are fulfilled an ECMWF staff member will review the PR and either merge the request or comment on the PR

The Contributor License Agreement (CLA)

All open source software packages at ECMWF are distributed under the Apache License 2.0. The standard Apache License was amended to cater for ECMWF special status as an international organisation. For you to be able to contribute any code to our software packages you need to agree that

  • ... you are happy for your code being redistribute under Apache License.
  • ... that your contribution does not violate anyone's IPR rights.

To so you and your organisation needs to sign a contributors agreement.

Tips to get your pull request merged

  1. Any contribution must be built with cmake and tested with ctest (see General CMake installation instructions)
  2. Make sure that all provided regression tests have passed correctly in your development system
  3. We encourage you to test changes with as many host and target combinations as is practical.
  4. Ideally we would encourage you to also implement a new unit test to validate your changes. However if this is not possible, please provide us with data and a procedure for us to create the new test.
  5. Make sure your changes are documented (Ideally JIRA issue and/or page on Confluence)
    1. Make function and variable names meaningful and follow existing conventions
    2. Add comments appropriately.
    3. Any Python code should ideally be PEP8 compliant