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

[Christopher Baines <mail@cbaines.net>]

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


Léo Le Bouter <lle-bout@zaclys.net> writes:

> It seems Fedora has automated infrastructure and feeds to monitor new
> upstream releases so that maintainers can get notifications on them.
>
> https://release-monitoring.org/
>
> Functional feed:
> https://apps.fedoraproject.org/datagrepper/raw?rows_per_page=1&delta=127800&category=hotness
>
> I could not find the actual data it is based on for release monitoring
> (like Debian watch files).

I think it might be in the service itself.

> I could not find a similar feed for Debian's watch/uscan but it would
> be nice if they provided some sort of RSS feed (global or scoped to
> packages or sets of packages).
>
> I am thinking we should really get something like this with the Guix
> Data Service, start including something similar to Debian uscan/watch
> rules in every package so we can get reliable (in majority of cases)
> update notifications.

I did spot these patches
https://patches.guix-patches.cbaines.net/project/guix-patches/list/?series=7298

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...

> We could also have some feature that gives you a feed for a manifest or
> operating-system definition so that people can prioritize work on what
> they care about easily.
>
> I would really love to have some RSS feed for new upstream releases
> from Guix Data Service based on my operating-system definition I would
> upload there.

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/...

> We could even go as far as preparing a patch (similar to guix refresh
> -u <pkg> && etc/committer.scm) and trying to build it and all it's
> dependents and if it doesnt cause any new failures we could send an
> automated patch contribution on guix-patches directly and tag it with
> "ci-update-ok" or something so a maintainer just has to double-check
> quickly and push (very efficient workflow).

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.

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).

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

I hope some of that makes sense,

Chris

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]