Move specs back into go-storage

[Xuanwo]

rs-storage maybe need to maintain their own definitions and don't need to have the same set with golang.

So how about move specs back into go-storage?

In order to not break links:

• Archive this repo instead of deleting it.
• Move all existing issues into go-storage.

After this change:

• we don't need to update go-storage's go.mod anymore.
• every project maintain their own proposals. (community, go-storage, beyond-tp)

[Xuanwo]

ping @beyondstorage/specs-committer @beyondstorage/specs-maintainer for a look.

[xxchan]

• Currently specs/definitions/ seems to be targeted to be cross language.

  rs-storage maybe need to maintain their own definitions and don't need to have the same set with golang.

  So you mean we don't need such cross-project specs any more. (And go-storage/cmd/definitions can also be refactored?) I'm OK with this part.

• We do need to split (or clarify) the scope of RFCs. Currently specs/rfcs/ is for organization, not only go-storage. Then the naming "GSP", short for "go-storage proposal" is confusing. And https://github.com/beyondstorage/beyond-tp has specs in its repo. (BTW, should we clarify the terms: GSP, RFC, proposal, spec (I'm OK with current status though))

  So we either move then, or use different directories, or state it clearly that RFCs for different projects are mixed (and stop calling them "GSP"). (BTW, IETF RFCs seem to be wide-ranging?)

• Will it be better that there's a special place for RFCs only? (I don't have a strong preference.)

  If RFCs are in the project repo, we may need to consider:

  • Will it be not as clean? There will be many things in issues. BTW, issue labels may be enough for a small organization like us? Another small problem is the issue numbers for RFCs will become more discontinuous and bigger?

  • We cannot distinguish 2 LGTMs for RFCs and 1 LGTM for other PRs automatically?

    BTW, currently, approval from reviewers is also not working and it needs a committer to merge the PR manually. But this is a little more strict than we want, so not very bad.

TLDR: I think we need some changes (or make things more clear), but don't have a style preference.

GitHub

beyondstorage/beyond-tp

Neutral data migration service. Contribute to beyondstorage/beyond-tp development by creating an account on GitHub.

[xxchan]

Oh, I thought /go and /rust are different, but they seem to do the same thing: parsing /definitions into data structures.

Then to make it clear, this repo contains definitions & RFCs:

• Cross-language (or cross-project) definitions: /definitions with language-specific parsing utilities: /go, /rust.
• /rfcs with /specs. I think /specs is confusing and we can consider removing it.

And we are considering moving both of them into project repos.
For definitions, I think moving /go into go-storage/definitions is totally OK. But I'm not sure whether to remove centralized /definitions.

[Xuanwo]

But I'm not sure whether to remove centralized /definitions.

I have to admit that we over-designed this feature.

Now, I think definition files are easy to maintain and we don't need to share them between different languages. After separation, we can be more focused on building up features instead of caring about behavior that across languages.

For definitions, I think moving /go into go-storage/definitions is totally OK.

Moving /go to go-storage without /definitions is impossible. Beacuse we use bindata to generate the ParsedPairs using definitions files.