Generic doc fixes to ipfs add

[RichardLitt]

License: MIT
Signed-off-by: Richard Littauer richard.littauer@gmail.com

[rht]

Went through the codebase looking for /an object/ pattern. Indeed the only place where it should be replaced with 'file' is in ipfs add, where the input is from any unixfs file.

[RichardLitt]

Good work, @rht

[rht]

LGTM

[rht]

(if anyone in @ipfs/go-ipfs-team or with yubikeys think this is a security hole, now is the time to handle it in a way you find appropriate)

[jbenet]

@rht nobody except @whyrusleeping and I are allowed to merge to master on this repo. And you knew that. When I granted access I explicitly said: no merging to master. Even though all this PRs LGTM and will remain merged, you've eroded my trust, and lost commit access. :( I cannot allow this. years down the road people will try to sneak in crypto vulnerabilities in ways like this.

[rht]

I broke the rule. I did not push anything malicious. I don't mind losing the commit access at all.
My compromise is if the process to speed up the dev can be implemented soon.

years down the road people will try to sneak in crypto vulnerabilities in ways like this.

It is years down the road when the protocol and the reference implementation have become stabler. For this (years later), yes, I agree of the security measure. For now, the protocol is still evolving a lot, yet much more than that are the implementation details: there are plenty perf, ux, security tweaks yet to be done, also pending of plenty features and integrations. If you (@jbenet+@whyrusleeping) see there is plenty to be done with all that, don't tighten the dev faucet yet. If you don't think so and you think I'm wrong, then please correct me, for I'd wish to learn...

I propose either any/all of the:

1. categorize the commits in how they are to be reviewed+merged, e.g. generic bug fixes, adding test cases, test improvements, features, api breaking, protocol changes, etc. Some could use a 2-of-n+bot mergebot. Use git blame stats to ping who should do the CR.
2. crystallize some of the CR requirements, so that there is less to CR. I have classified some generic ones from the past: signoff reminder, gofmt, test, don't break interface compatibility, don't duplicate code, etc. Much like js the good parts, which was turned into a linter. There is the gofmt check script (still optional) which could be put into makefile. https://github.com/ipfs/community/blob/master/go-contribution-guidelines.md. cc: @RichardLitt
3. split go-ipfs so that the components can move faster with the designated maintainers, extracted from the git blame stats (e.g. gateway Yank gateway out to a separate repo #2006 (there is the question of the pending gateway PRs), commands/file). Though this being practical depends on whether gx is ready to use.

3 is already partially done, if this can be done sooner, since the dev0.4.0 bottleneck has gone.