Re: Fedora/Debian release monitoring inspiration for Guix Data Service

["Léo Le Bouter" <lle-bout@zaclys.net>]

[-- Attachment #1: Type: text/plain, Size: 3099 bytes --]

On Tue, 2021-03-16 at 23:28 +0000, Christopher Baines wrote:
> I did spot these patches
> https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=7298

Awesome!! I did not see them earlier!

> I think the Guix Data Service could run the "refresh" code from Guix
> and
> store relevant data, although I'm also thinking along the lines of
> trying to generate patches, like you go on to below...

Yes :-D

> So, one thing I'm hoping to start work on in the coming weeks/months
> is
> the long awaited service for providing subscriptions/notifications
> for
> the Guix Data Service (+ other services).
> 
> My current plan is to use a WebSub like pattern, but this could
> easily
> be adapted to RSS/email/...

That sounds very great! I know you've been working on this, but I also
wanted (through my email) try to make more people aware and draw
attention to the subject of automation in GNU Guix.

> Yeah, one problem with the current automated patch review stuff I've
> got
> going at the moment is that there's no feedback when the Guix Data
> Service finds out that things do/don't build.

Yes, and because of that the Guix Data Service and guix-build-
coordinator-agent thing you are running goes mostly unused (even for
me!).

> However, as I also set out above, there's been a plan and design for
> making that possible for years, it just needs implementing.
> 
> One thing I'm hoping to do once it's possible to subscribe to Guix
> Data
> Service data is make the checks in Patchwork actually reflective of
> results (like 4 packages broken by these changes), rather than just
> providing links, and someone having to figure out what information is
> hidden within.
> 
> Those same subscriptions could be used to prompt people to look at
> patches for package updates that don't introduce breakages (following
> what you set out above).

+1000

> The pieces are slowly coming together for this, at least with the way
> I
> would approach it. For example, it's possible to get commits in to
> data.guix-patches.cbaines.net now by just pushing to the Git
> repository,
> so to set out something similar to what you describe above:
> 
>  - Some service watches for new releases (through the guix refresh
>    code), and then makes commits, and pushes them to a Git repo
> 
>  - There's a Guix Data Service reading from that Git repository, it
>    starts processing the changes
> 
>  - Something (probably the "service" above") subscribes to find out
> when
>    relevant information is available (like build successes/failures)
> 
>  - Builds happen via the Guix Build Coordinator, which feeds
> information
>    back to the Guix Data Service
> 
>  - That "service" gets the notifications that the commits are good,
> and
>    prompts someone to review them

All awesome! Can't wait! As soon as I can I will make sure to help, I
am reading through the GNU Guile manual, need to find more
concentration time.

> I hope some of that makes sense,
> 
> Chris

Thanks a lot Chris for all this!!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]