[bug#69964] [PATCH 0/4] gnu: Add go-github-com-multiformats-go-multibase.

[Sharlatan Hellseher]

Hi,

I've checked https://github.com/multiformats, and it looks like a very
nice project which is in use by others large ones:

- IPFS https://ipfs.tech/
- CIDs https://github.com/multiformats/cid
- libp2p https://github.com/libp2p/libp2p
- IPLD https://github.com/ipld/ipld

> Should I create "encodings.scm"?  Or maybe "specs.scm" is a better name
> for it?  Because if there will be need for other protocol/format
> specifications we can place the packages to "specs.scm".

I'm not quite sure what to answer here, after a brief check of any
relevant modules. I've only found that there are only language specific
*-base* packages.

I'll give it another round to find some appropriate place for
specification distributed as CSV file from
<https://github.com/multiformats/multibase>, or we may ping someone else
from core/mentor team.

Based on the project's check, they provide verity language
implementations e.g. in Rust, Python, Go, Java, JavaScript so having
spec file in golang-*.scm is not the best place.

> Also what is the proper way to update the patch series?

I can't suggest any tooling, just describe my common flow.

I usually create patches on my local Guix checkout branch e.g.
'local/astro-update' and I use Emacs's Magit. If I need new patch series
I pull all, rebase on master select amended/update commits and place
new version prefix.

In short, use the same commit headers but add prefix 'PATCH v2' which
will be identified nicely by QA and the patch series may be obtained
much easily.

--
Oleg

signature.asc
Description: PGP signature