-
Notifications
You must be signed in to change notification settings - Fork 12
Contributing
As a non collaborator
- Fork this repository
- Make a new branch
- Make your changes
- Make a pull request
- Continue to merge master into your branch while your PR waits. You know your code and are thus best suited to fix any merge conflicts that may arise. Then, collaborators can merge cleanly and we'll all be happy.
As a collaborator
- Make a new branch on this repository
- Make your changes
- Make a pull request, and wait for confirmation at least one other dev.
- label it "PR: Ready"
We are using tabs for indentations. Don't like it? I don't either, but it's our standard so please fucking follow it. Fortunately, we are allowed to use spaces to align code. Will this cause a mess aligning using different tab sizes? Yes. So let's all agree to use tabsize=8, alright? I didn't decide this one.
gTorrent uses astyle to format our code. You can find more about it here
Install astyle, and then run scripts/format.sh at the root of the repo, so that someone else doesn't have to fix your retarded indents
No need to worry about this as scripts/format.sh will format your code for you. We are using Allman/ANSI (Blocks have their own opening braces).
Avoid stupid fucking c++ shitty meta programming templates whenever possible.
// something or other
Class members start with m_ (maybe remove this)
libtorrent-rasterbar:
Merge a PR into master only after the dev has tested it, consider it stable, and has merged master into his branch (the merge button should be green and you shouldn't need to resolve conflicts). Pull requests should be approved by at least one other dev (even if submitter is a dev) before merging.
Version releases
- use
git tag - update
CHANGELOG - update
CMakeLists.txt
contributing scroll up