Add some explanation to the README #8
Conversation
License: MIT Signed-off-by: Rob Brackett <[email protected]>
|
|
||
| This repo is used to discuss and draft a specification for the next version of UnixFS (the DAG node format used to represent *files and directories* on the IPFS network). You can find and participate in discussion about desired features in [the issues](https://github.com/ipfs/ipld-unixfs/issues) and an [initial specification draft in PR #2](https://github.com/ipfs/ipld-unixfs/pull/2). | ||
|
|
||
| When the specification draft is complete, it will be moved to the `ipfs/specs` repo at https://github.com/ipfs/specs/tree/master/unixfs and this repo will likely be re-dedicated to building the **Go** implementation of UnixFS. |
There was a problem hiding this comment.
This part is not certain, so let's leave this paragraph out for now.
There was a problem hiding this comment.
Which part, adding it to the specs repo or repurposing this repo?
When I talked with @whyrusleeping on Slack, it sounded like he was saying both were pretty certain (also that it might make sense to rename this repo to go-*, but that was not at all certain). @whyrusleeping, did I misunderstand?
There was a problem hiding this comment.
I was not part of this discussion. @whyrusleeping specifically asked me to create this repo for the point of moving the spec along. He never mentioned anything about moving it to ipfs/specs to me.
There was a problem hiding this comment.
Ok. It sounds like there are some parts of this that people have different understandings of. This seems like a good opportunity to get that cleared up.
So…
- Is the intent to copy this back to
ipfs/specs/unixfs(when it’s ready, whatever stage of finalization that may be) correct/agreed on? - What does everyone understand to be the future of this repo after a draft for the next version of the UnixFS spec is done? (If this stays separate from
ipfs/specs, what does that mean for future work on other specs that are currently housed there?)
There was a problem hiding this comment.
The right thing for us to do, in terms of project organization, is to make the spec output of this repo become a part of the main specs repo, and this repo to be transitioned into a go implementation of said spec.
|
This LGTM except for the last paragraph. |
|
I’m going to go ahead and merge this tomorrow, since it’s all approved. Let me know if that’s not ok. |
|
@Mr0grog for sure, for most repos that arent the primary entrypoints, contributors are able to merge anything after getting proper review |
When new folks are pointed to this repo, it appears totally empty and can be pretty confusing (see this exchange, for example), so I’ve drafted this simple README to help explain what’s going on here. Based off a conversation with @whyrusleeping and @lanzafame on IRC and Slack.
Alternatively, @whyrusleeping noted this all might belong in
ipfs/specs. If someone wants to just port everything over now, I’ll change the text here to say it’s a placeholder for the Go implementation. Otherwise, this will really help folks understand the repo until that gets sorted out.