Hi,

I've pushed the split III to master.
- https://issues.guix.gnu.org/68605
- https://debbugs.gnu.org/cgi/bugreport.cgi?bug=68605

And it's picked up by CI.
- https://ci.guix.gnu.org/eval/1082575

> Hmm, there seems to be a limit in the degree of parallelizability in
> this process unfortunately. But if there's anything you can think of
> that could help (manually) in this effort, then I'd be happy to help!

I think you may help! The identification of the group is still human
decision making process and I'm not sure it may be automated in any point.
So...
There are golang dedicated modules now and few more coming soon!

Each of the module header contains a short annotation which packages it
expects to have, feel free to improve it to make it even more clear
for others.

- golang-check
- golang-web
- golang-crypto

TBA:
- golang-compression :: Anything related to that subject, see
  python-compression, java-compression, perl-compression.

- golang-build or golang-extension :: Any low level golang add-ons not
included in core distribution see <https://pkg.go.dev/golang.org/x> or
any 0 dependencies high reference modules.

- golang-xyz :: As any other *-xyz module would absorb anything else
  left behind.

Maybe:
- golang-graphics
- golang-maths / golang-science
- ...

> 1. Put a magic comment above each package that you would like to move.
> 2. Run a simple script that makes a note of all of these into a
> to-move-list.
> 3. Then stash the change with the comments you made (in case you need
> to change things)
> 4. Run another script that takes the package list and performs the
> move in one's repository.
> 5. Sort out the use-package declarations manually and run tests.
> 6. When satisfied, stash the change and keep just the use-package
> changes.
> 7. Run a final script that loops through all the packages and commits
> each one in turn.
> 8. Rebase to suit.

We may extend handy script accelerating committing process, see
"etc/committer.scm"

> - I'm not a scheme programmer, but I did use Haskell at university so
>  I'm familiar with thinking in a functional style.
Me too =), but you still can help by just providing some review to
existing code base and available packages in golagn.scm and trying to
identify close group for each of them.

> I'm also imagining some the possibility of having a script that can
> remove redundant #:use-module's in the future, though I don't know if
> we care about a few unneeded modules being included.
The clean up task may be organasied after sort process is completed, having
not required #:use-module does not hurt too much but for keeping modules
tidy and fast to load it definitely beneficial.

Regards,
Oleg