GNU bug report logs -
#69964
[PATCH 0/4] gnu: Add go-github-com-multiformats-go-multibase.
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
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 (application/pgp-signature, inline)]
This bug report was last modified 1 year and 106 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.