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 contact ECMWF Software Support.


The purpose of the GitHub ECMWF space

ECMWF tries to provide a set-up which allows fast integration of changes from various parties but does not impact on stability by allowing developers to pull changes at their convenience.


 

Developers always contribute to their local repos first, before they file pull requests to the master repository. Developers can pull changes from master at their discretion.

The process

 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. Make the necessary code changes & add tests to ensure the new codes works as intended
  3. Run the tests which come with the package and verify that no regressions have occurred
  4. 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
  5.  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