FOSSology
4.4.0
Open Source License Compliance by Open Source Software
|
We welcome contributions in several forms, e.g.
FOSSology uses GitHub's issue tracker. All bugs and enhancements should be entered so that we don't lose track of them, can prioritize, assign, and so code fixes can refer to the bug number in its check-in comments.
The issue usually contains much more detail (including test cases) than can be reasonably put in check-in comments, so being able to correlate the two is important.
Consider the usual best practice for writing issues, among them:
follow the Coding Style
Not familiar with git, see Git basic commands
We are using the Feature Branch Workflow (also known as GitHub Flow), and prefer delivery as pull requests.
Our first line of defense is the Travis CI build defined within .travis.yml and triggered for every pull request.
Create a feature branch:
The cardinal rule for creating good commits is to ensure there is only one "logical change" per commit. Why is this an important rule?
Things to avoid when creating commits
We use git commit as per Conventional Changelog:
Example:
Allowed types:
You can add additional details after a new line to describe the change in detail or automatically close an issue on Github.
NOTE: CHANGELOG.md is generated based on the commits.
All commits not submitted via GitHub pull request shall contain a Signed-off-by line, also known as the Developer Certificate of Origin (DCO) as we know it from the Linux Kernel Documenation/SubmittingPatches
Additional tags in addition to Signed-off-by shall be used as long as it makes sense for any commit, e.g.
Pull requests with patches, improvements, new features are a great help. Please keep them clean from unwanted commits.
Follow the steps to get your work included in the project.
<githubId>/#<issueNr>/<description/scope/topic>
Example:
Or
4) It's coding time! Please respect the coding convention: Coding guidelines
Commit your changes in logical chunks. Please adhere to Git Commit Conventions and Coding guidelines or your code is unlikely to be merged into the main project. Use Git's interactive rebase feature to tidy up your commits before making them public.
5) Locally rebase the upstream master branch into your topic branch:
6) Push your topic branch up to your fork:
7) Open a Pull Request with a clear title and description against the master
branch.
The FOSSology project does not require you to assign the copyright of your contributions, you retain the copyright. The FOSSology project does require that you make your contributions available under the [GNU General Public License as published by the Free Software Foundation, version 2](LICENSE), in order to be accepted as a contribution in the main repo.
If appropriate, include the GPLv2 license header at the top of each file along with the copyright info. If you are adding a new file that you wrote, include your name in the copyright notice in the license summary.