From 97c595e233bb018542164a1795e93d43a7883083 Mon Sep 17 00:00:00 2001 From: Molly Date: Wed, 17 Oct 2018 14:58:37 +0100 Subject: [PATCH] Change to point to combined contributing guidelines License: MIT Signed-off-by: Molly Mackinlay --- CONTRIBUTING.md | 7 +++ contribute.md | 121 ------------------------------------------------ 2 files changed, 7 insertions(+), 121 deletions(-) create mode 100644 CONTRIBUTING.md delete mode 100644 contribute.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..96846dae0 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,7 @@ +IPFS as a project, including go-ipfs and all of its modules, follows the (standard IPFS Community contributing guidelines)[https://github.com/ipfs/community/blob/master/CONTRIBUTING.md]. + +We also adhere to the (GO IPFS Community contributing guidelines)[https://github.com/ipfs/community/blob/master/CONTRIBUTING_GO.md] which provide additional information of how to collaborate and contribute in the Go implementation of IPFS. + +We appreciate your time and attention for going over these. Please open an issue on ipfs/community if you have any questions. + +Thank you. diff --git a/contribute.md b/contribute.md deleted file mode 100644 index 87ddcae9d..000000000 --- a/contribute.md +++ /dev/null @@ -1,121 +0,0 @@ -# Contribute - -go-ipfs is MIT licensed open source software. We welcome contributions big and -small! Take a look at the [community contributing notes](https://github.com/ipfs/community/blob/master/contributing.md). - -Please make sure to check out the [issues](https://github.com/ipfs/go-ipfs/issues). Search the closed ones before reporting things, and (if you can!) help us with open ones. - -Please note that the go-ipfs issues are only for bug reports and directly actionable features. Check [the IPFS Community guide on reporting issues](https://github.com/ipfs/community/blob/master/contributing.md#reporting-issues) if your question doesn't fit as a bug report or an actionable feature, and our [guide on opening issues](https://github.com/ipfs/go-ipfs/blob/master/docs/github-issue-guide.md) if you are not sure how to make an issue here. - -If you're looking to help out, head to the [captain's log](https://github.com/ipfs/go-ipfs/issues/2247) and -try picking up an issue from there. - -## Go Guidelines: - -Please look and conform to our [Go Contribution Guidelines](https://github.com/ipfs/community/blob/master/go-code-guidelines.md). - -## General Guidelines: - -- See the [dev pseudo-roadmap](dev.md). -- Please adhere to the protocol described in [the main ipfs repo](https://github.com/ipfs/ipfs) and [specs](https://github.com/ipfs/specs) (WIP). -- Please make branches and pull-request, even if working on the main repository. -- Ask questions or talk about things in [Issues](https://github.com/ipfs/go-ipfs/issues) or #ipfs on freenode. -- Ensure you are able to contribute (no legal issues please-- we'll probably setup a CLA). -- Have fun! - -## Repository specific guidelines: - -### Each Commit Must Pass Tests - -All commits in a PR must pass tests. If they don't, fix the commits and/or [squash them](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Squashing-Commits) so that they do pass the tests. This should be done so that we can use git-bisect easily. - -We use CI tests which run when you push to your branch. To run the tests locally, you can run any of these: `make build`, `make install`, `make test`, `go test ./...`, depending on what you're looking to do. Generally `go test ./...` is your best bet. - -### Branch Names - -If you are working on a new feature, prefix your branch name with `feat/`. If you are fixing an issue, `fix/`. If you are simply adding tests, `test/`. If you are adding documentation, `doc/`. If your changeset doesn't fall into one of these categories, use your best judgement and come up with your own short prefix. - -After that, try to signal what part of the codebase this branch is working on. For example, if you are adding a new test to the DHT that tests for nil providers being returned, then `test/dht/nil-provs` would be acceptable. If your changes don't fall cleanly in a single module, you can use a more general descriptor, or leave it off in favor of a slightly more wordy description. - -Please also try to keep branch names around or under 20 characters. It keeps things a little cleaner overall. Also try to avoid putting issue numbers in branch names, it takes up space without providing any immediately relevant context about the changeset. - -A few examples of good branch names: - -- `feat/cmds/object-diff` - - For a Pull Request that adds an `ipfs object diff` command. -- `test/dag/cache-invalid` - - For adding tests around the merkledag's cache invalidation code. -- `doc/unixfs/pkg-desc` - - For a branch that adds or improves the package description in unixfs. - -### Commit messages - -Commit messages must start with a short subject line, followed by an optional, -more detailed explanatory text which is separated from the summary by an empty line. -We use [GitCop](https://gitcop.com) to check that commit messages are -properly written. It checks the following: - -* The first line of a commit message, called the subject line should - not be more than 80 characters long. - -* The commit message should end with the following trailers: - - ``` - License: MIT - Signed-off-by: User Name - ``` - - where "User Name" is the author's real (legal) name and - email@address is one of the author's valid email addresses. - - These trailers mean that the author agrees with the - [developer certificate of origin](docs/developer-certificate-of-origin) - and with licensing the work under the [MIT license](docs/LICENSE). - - To help you automatically add these trailers, you can run the - [setup_commit_msg_hook.sh](https://raw.githubusercontent.com/ipfs/community/master/dev/hooks/setup_commit_msg_hook.sh) - script which will setup a Git commit-msg hook that will add the above - trailers to all the commit messages you write. - -See the [documentation about amending commits](https://github.com/ipfs/community/blob/master/docs/amending-commits.md) -for explanation about how you can rework commit messages. - -Some example commit messages: - -``` -parse_test: improve tests with stdin enabled arg - -Now also check that we get the right arguments from -the parsing. - -License: MIT -Signed-off-by: Christian Couder -``` - -and - -``` -net/p2p + secio: parallelize crypto handshake - -We had a very nasty problem: handshakes were serial so incoming -dials would wait for each other to finish handshaking. this was -particularly problematic when handshakes hung-- nodes would not -recover quickly. This led to gateways not bootstrapping peers -fast enough. - -The approach taken here is to do what crypto/tls does: -defer the handshake until Read/Write[0]. There are a number of -reasons why this is _the right thing to do_: -- it delays handshaking until it is known to be necessary (doing io) -- it "accepts" before the handshake, getting the handshake out of the - critical path entirely. -- it defers to the user's parallelization of conn handling. users - must implement this in some way already so use that, instead of - picking constants surely to be wrong (how many handshakes to run - in parallel?) - -[0] http://golang.org/src/crypto/tls/conn.go#L886 - -License: MIT -Signed-off-by: Juan Benet -```