Skip to content

Latest commit

 

History

History
77 lines (53 loc) · 4.4 KB

CONTRIBUTING.md

File metadata and controls

77 lines (53 loc) · 4.4 KB

Contributing to SPQlios-fft

The spqlios-fft team encourages contributions. We encourage users to fix bugs, improve the documentation, write tests and to enhance the code, or ask for new features. We encourage researchers to contribute with implementations of their FFT or NTT algorithms. In the following we are trying to give some guidance on how to contribute effectively.

Communication

Communication in the spqlios-fft project happens mainly on GitHub.

All communications are public, so please make sure to maintain professional behaviour in all published comments. See Code of Conduct for guidelines.

Reporting Bugs or Requesting features

Bug should be filed at https://github.com/tfhe/spqlios-fft/issues.

Features can also be requested there, in this case, please ensure that the features you request are self-contained, easy to define, and generic enough to be used in different use-cases. Please provide an example of use-cases if possible.

Setting up topic branches and generating pull requests

This section applies to people that already have write access to the repository. Specific instructions for pull-requests from public forks will be given later.

To implement some changes, please follow these steps:

  • Create a "topic branch". Usually, the branch name should be username/small-title or better username/issuenumber-small-title where issuenumber is the number of the github issue number that is tackled.

  • Push any needed commits to your branch. Make sure it compiles in CMAKE_BUILD_TYPE=Debug and =Release, with -DWARNING_PARANOID=ON.

  • When the branch is nearly ready for review, please open a pull request, and add the label check-on-arm

  • Do as many commits as necessary until all CI checks pass and all PR comments have been resolved.

    During the process, you may optionnally use git rebase -i to clean up your commit history. If you elect to do so, please at the very least make sure that nobody else is working or has forked from your branch: the conflicts it would generate and the human hours to fix them are not worth it. Git merge remains the preferred option.

  • Finally, when all reviews are positive and all CI checks pass, you may merge your branch via the github webpage.

Keep your pull requests limited to a single issue

Pull requests should be as small/atomic as possible.

Coding Conventions

  • Please make sure that your code is formatted according to the .clang-format file and that all files end with a newline character.
  • Please make sure that all the functions declared in the public api have relevant doxygen comments. Preferably, functions in the private apis should also contain a brief doxygen description.

Versions and History

  • Stable API The project uses semantic versioning on the functions that are listed as stable in the documentation. A version has the form x.y.z

    • a patch release that increments z does not modify the stable API.
    • a minor release that increments y adds a new feature to the stable API.
    • In the unlikely case where we need to change or remove a feature, we will trigger a major release that increments x.

    If any, we will mark those features as deprecated at least six months before the major release.

  • Experimental API Features that are not part of the stable section in the documentation are experimental features: you may test them at your own risk, but keep in mind that semantic versioning does not apply to them.

If you have a use-case that uses an experimental feature, we encourage you to tell us about it, so that this feature reaches to the stable section faster!

  • Version history The current version is reported in manifest.yaml, any change of version comes up with a tag on the main branch, and the history between releases is summarized in Changelog.md. It is the main source of truth for anyone who wishes to get insight about the history of the repository (not the commit graph).

Note: The commit graph of git is for git's internal use only. Its main purpose is to reduce potential merge conflicts to a minimum, even in scenario where multiple features are developped in parallel: it may therefore be non-linear. If, as humans, we like to see a linear history, please read Changelog.md instead!