ECMWF provides various levels of software codes, ranging from training codes and scripts, research projects to software supporting the production services. ECMWF has five spaces on GitHub and software are assign according to the use and support level:
| GitHub space | Purpose | Support |
|---|---|---|
| ecmwf | ECMWF official software packages | Support is given under the rules of ECMWF's Software Support. Users should report issues by email to Software.Software@ecmwf.int or in the Software Support page at ECMWF |
| ecmwf-projects | Codes for addressing scientific challenges or technical tasks which are aimed at specific user groups. | There is no support commitment by ECMWF and users should contact the maintainers of the respective GitHub repository. (Checklist to add a repo there) |
| ecmwf-lab | ECMWF codes for explorative work and one-off training and development activities. These codes might not be suitable for production use. | No support by ECMWF, please contact developers within GitHub repository. (Checklist to add a repo there) |
| ecmwf-ifs | Selected components of IFS that are available as open-source | No support by ECMWF, please contact developers within GitHub repository. (Checklist to add a repo there) |
| esowc | European Summer of Weather Code (ESoWC) projects | No support by ECMWF, please contact developers within GitHub repository. |
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.
Please note that many ECMWF git repositories are not self-contained! Many repositories require the ecBuild repository to be cloned/forked as well to be able to build the software. If the ecbuild repository is placed at the same level in your directory structure as the software package you intend to build, it should be found automatically. |
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:
- Fork the master branch of the targeted package from GitHub to your own GitHub space
- Clone your fork locally
- Make the necessary code changes & add and run tests to ensure the new codes works as intended
- Push changes back to fork on GitHub
- Create a pull request (PR) back to ECMWF:
- Describe the motivation of the change and impact on code
- Accept the ECMWF Contributors License Agreement (CLA - see below for more information)
- Make sure that all requirements of the PR are addressed
- 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 to be redistributed under Apache License.
- ... that your contribution does not violate anyone's Intellectual Property Rights (IPR).
To do so, you and your organisation need to sign a contributors agreement.
At the beginning you see this comment -
press on the button "CLA not signed yet" and accept the agreement:
After this you will see the button becomes green:
Tips to get your pull request merged
- Any contribution must be built with cmake and tested with ctest (see General CMake installation instructions)
- Make sure that all provided regression tests have passed correctly in your development system
- We encourage you to test changes with as many host and target combinations as is practical.
- 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.
- Make sure your changes are documented (Ideally JIRA issue and/or page on Confluence)
- Make function and variable names meaningful and follow existing conventions
- Add comments appropriately.
- Any Python code should ideally be PEP8 compliant