On Mon, Jan 08, 2024 at 02:51:39AM +0100, Wilko Meyer wrote:
> Hi Guix,
> 
> I started packaging atuin[0], a tool written in Rust to keep ones shell
> history in sync across systems/make it more easily searchable, for Guix.
> It builds successfully on my system already from a manifest.scm, so I
> decided to create a patchset for Guix proper. I'm almost certain,
> there'll be a v2 of this patch series; as some package description do
> not fully comply with the preferred style yet, I want to add the proper
> cargo-development-inputs to dependencies where applicable, smooth rough
> edges,and want to see if I get the sync server implementation for atuin
> running as a shepherd service.
> 
> As this patch series got pretty big, I'm not sure what the best way is
> to get all changes/atuin into Guix proper. Is it even feasible like this
> from a reviewing perspective or should I see if I can split up this
> patch series in 3 (atuin cli tool, and the two server implementations,
> one for postgresql and one for sqlite) seperate ones?

I assume you need the CLI tool and one of the server implementations to
make it work? I'd go with the CLI tool and the sqlite implementation
since that's always easy to work with.

I've applied a bunch of the patches, but I want to ask you to try to
build more of the crates instead of skipping the builds and to insert
them alphabetically.  Its easiest for me if each patch can be applied
after the previous one(s) and then build, but I'm not averse to applying
groups of them and then checking them together, for example the
rust-rocket-* patches or something similar. Then its not too bad to go
and slot in a couple of fixup commits to make any changes.

-- 
Efraim Flashner   <efraim@flashner.co.il>   רנשלפ םירפא
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted