Hi Denis,

> I was already unsure about the patch I sent. In the v2 should I do it
> all at once in a single patch or should I split the work across multiple
> patches?

I would suggest to think about the flow, let's say:

* Unbundle as many as possible first, and make it as a single patch
(which should pass build, test, lint etc.)

* Review the massive dependence tree and split it in some sort of
logical blocks/future series which should be self contain and build
individually or when series applied as a whole.

* Start unwind it slowly let's say by 8-12 packages per series, making
sure each series may be apply directly on current master and may be
built.

We may reduce amount of noise to bug-tracker and keep on track with
unbundle process without too much stress and time requiring to review
100++ series

To keep you in a peas of mind - you are not alone in that hard work and
your efforts will be enforced by others who updates/unbunle Golang
packages the more we have the less effort we need to apply to unbunle as
some of the package may be reused.

In short, keep eye on current master and go-team branches and do
rebate/pul often.

I'm waiting for my turne to merge go-team and will continue on the work
with unbundling kubo which will bring about 300 packages.

Some neat-pick give a try to use "guix import go --recursive
<module/name>" on go-team branch which has much better performance than
available in current master.

--
Thanks,
Oleg