Getting Started¶
Branches¶
- Current development branch:
devel
- Branch namespace for release & development:
releases/<release_id>
Pull requests¶
- Before you start working on a pull request, open an issue and discuss your ideas with the AVD maintainers. This will help prevent wasting time on something we might be unable to implement. When suggesting a new feature, ensure it will be consistent with all work already in progress.
- Any pull request which doesn’t relate to an accepted issue will not be approved.
- All major new functionality must include relevant molecule tests where applicable.
- When submitting a pull request, please rebase from the
devel
branch rather than a release branch:releases/*
. This is because thedevel
branch is used for ongoing development, whilereleases/*
are used for tagging new stable releases.
-
All code submissions should meet the following criteria (CI will enforce these checks):
- YAML syntax is valid
- Python syntax is valid
- All tests pass when run with
make sanity
- PEP 8 compliance is enforced, with the exception that lines may be greater than 80 characters in length
Adhering to the following process is the best way to get your work merged:
-
Fork the repository, clone your fork, and configure the remotes:
-
If you cloned a while ago, get the latest changes from upstream:
-
Create a new topic branch (off the main project development branch) to contain your feature, change, or fix:
- Commit your changes in logical chunks. Please adhere to these Git commit message guidelines, or your code will unlikely be merged into the main project. Use Git’s git rebase feature to tidy up your commits before making them public.
-
Locally merge (or rebase) the upstream development branch into your topic branch:
-
Push your topic branch up to your fork:
- Open a Pull Request with a clear title, description, and following the template.