guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#76960] [sysadmin-team PATCH 0/8] Update spdlog.


From: Greg Hogan
Subject: [bug#76960] [sysadmin-team PATCH 0/8] Update spdlog.
Date: Sun, 16 Mar 2025 12:44:09 -0400

On Wed, Mar 12, 2025 at 8:52 AM Maxim Cournoyer
<maxim.cournoyer@gmail.com> wrote:
>
> Hi Greg,
>
> Greg Hogan <code@greghogan.com> writes:
>
> > All dependent packages build except rxcpp, which is broken on master.
> >
> > Greg Hogan (8):
> >   gnu: spdlog: Update to 1.15.1.
> >   gnu: Add spdlog-1.13.
> >   gnu: gerbera: Pin spdlog.
> >   gnu: gr-satellites: Pin spdlog.
> >   gnu: kddockwidgets: Pin spdlog.
> >   gnu: mtxclient: Pin spdlog.
> >   gnu: nheko: Pin spdlog.
> >   gnu: waybar: Pin spdlog.
>
> We usually keep one change per patch, but in cases where we know that
> there is breakage and how to fix it, it's nicer to combine the changes
> in one atomic commit to ensure all the packages remain working on any
> give commit (could be useful while travelling with 'guix time-machine'
> for example).
>
> Could you squash the series and submit as v2?  Thanks!
>
> --
> Thanks,
> Maxim

Maxim,

Thank you for the recommendation. I can certainly see this as two
multi-package patches:
1) updating a package while leaving the old version pinned (spdlog)
2) the same trivial update to multiple packages (the six dependent packages)

And this would simplify the commit logs and reduce the mailing list
traffic. But it doesn't seem practical to squash all updates into the
original breaking commit. When updating glibc or gcc the core-packages
team fixes hundreds of packages, and the kde and gnome updates
similarly make changes across dozens of packages. More useful than
random hopping with time-machine would be scheduled releases (or
marking the span or end of each patchset with the patch ID).

Greg





reply via email to

[Prev in Thread] Current Thread [Next in Thread]