@cryptotaxi247 / kubo / commits / 97c595e23

Change to point to combined contributing guidelines

License: MIT Signed-off-by: Molly Mackinlay <molly@protocol.ai>

Molly committed Oct 17, 2018 at 14:58 UTC 97c595e233bb018542164a1795e93d43a7883083

2 files changed +7 -121

CONTRIBUTING.md new

@@ -0,0 +1,7 @@

1 +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].

2 +

3 +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.

4 +

5 +We appreciate your time and attention for going over these. Please open an issue on ipfs/community if you have any questions.

6 +

7 +Thank you.

contribute.md deleted

-121

@@ -1,121 +0,0 @@

1 -# Contribute

2 -

3 -go-ipfs is MIT licensed open source software. We welcome contributions big and

4 -small! Take a look at the [community contributing notes](https://github.com/ipfs/community/blob/master/contributing.md).

5 -

6 -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.

7 -

8 -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.

9 -

10 -If you're looking to help out, head to the [captain's log](https://github.com/ipfs/go-ipfs/issues/2247) and

11 -try picking up an issue from there.

12 -

13 -## Go Guidelines:

14 -

15 -Please look and conform to our [Go Contribution Guidelines](https://github.com/ipfs/community/blob/master/go-code-guidelines.md).

16 -

17 -## General Guidelines:

18 -

19 -- See the [dev pseudo-roadmap](dev.md).

20 -- Please adhere to the protocol described in [the main ipfs repo](https://github.com/ipfs/ipfs) and [specs](https://github.com/ipfs/specs) (WIP).

21 -- Please make branches and pull-request, even if working on the main repository.

22 -- Ask questions or talk about things in [Issues](https://github.com/ipfs/go-ipfs/issues) or #ipfs on freenode.

23 -- Ensure you are able to contribute (no legal issues please-- we'll probably setup a CLA).

24 -- Have fun!

25 -

26 -## Repository specific guidelines:

27 -

28 -### Each Commit Must Pass Tests

29 -

30 -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.

31 -

32 -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.

33 -

34 -### Branch Names

35 -

36 -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.

37 -

38 -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.

39 -

40 -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.

41 -

42 -A few examples of good branch names:

43 -

44 -- `feat/cmds/object-diff`

45 - - For a Pull Request that adds an `ipfs object diff` command.

46 -- `test/dag/cache-invalid`

47 - - For adding tests around the merkledag's cache invalidation code.

48 -- `doc/unixfs/pkg-desc`

49 - - For a branch that adds or improves the package description in unixfs.

50 -

51 -### Commit messages

52 -

53 -Commit messages must start with a short subject line, followed by an optional,

54 -more detailed explanatory text which is separated from the summary by an empty line.

55 -We use [GitCop](https://gitcop.com) to check that commit messages are

56 -properly written. It checks the following:

57 -

58 -* The first line of a commit message, called the subject line should

59 - not be more than 80 characters long.

60 -

61 -* The commit message should end with the following trailers:

62 -

63 - ```

64 - License: MIT

65 - Signed-off-by: User Name <email@address>

66 - ```

67 -

68 - where "User Name" is the author's real (legal) name and

69 - email@address is one of the author's valid email addresses.

70 -

71 - These trailers mean that the author agrees with the

72 - [developer certificate of origin](docs/developer-certificate-of-origin)

73 - and with licensing the work under the [MIT license](docs/LICENSE).

74 -

75 - To help you automatically add these trailers, you can run the

76 - [setup_commit_msg_hook.sh](https://raw.githubusercontent.com/ipfs/community/master/dev/hooks/setup_commit_msg_hook.sh)

77 - script which will setup a Git commit-msg hook that will add the above

78 - trailers to all the commit messages you write.

79 -

80 -See the [documentation about amending commits](https://github.com/ipfs/community/blob/master/docs/amending-commits.md)

81 -for explanation about how you can rework commit messages.

82 -

83 -Some example commit messages:

84 -

85 -```

86 -parse_test: improve tests with stdin enabled arg

87 -

88 -Now also check that we get the right arguments from

89 -the parsing.

90 -

91 -License: MIT

92 -Signed-off-by: Christian Couder <chriscool@tuxfamily.org>

93 -```

94 -

95 -and

96 -

97 -```

98 -net/p2p + secio: parallelize crypto handshake

99 -

100 -We had a very nasty problem: handshakes were serial so incoming

101 -dials would wait for each other to finish handshaking. this was

102 -particularly problematic when handshakes hung-- nodes would not

103 -recover quickly. This led to gateways not bootstrapping peers

104 -fast enough.

105 -

106 -The approach taken here is to do what crypto/tls does:

107 -defer the handshake until Read/Write[0]. There are a number of

108 -reasons why this is _the right thing to do_:

109 -- it delays handshaking until it is known to be necessary (doing io)

110 -- it "accepts" before the handshake, getting the handshake out of the

111 - critical path entirely.

112 -- it defers to the user's parallelization of conn handling. users

113 - must implement this in some way already so use that, instead of

114 - picking constants surely to be wrong (how many handshakes to run

115 - in parallel?)

116 -

117 -[0] http://golang.org/src/crypto/tls/conn.go#L886

118 -

119 -License: MIT

120 -Signed-off-by: Juan Benet <juan@ipfs.io>

121 -```