Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 11:52 PM Paul Wise <pabs@debian.org> wrote:
>
> On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote:
>
> > If I understand correctly, release-monitoring already offers such a
> > mapping [1].
>
> It seems like the Ayanita distro mapping needs to be done manually once
> per package, while using the Repology data would automatically get us
> the mapping for each existing package and all future packages.
I mean it looks rather easy to do, just a couple of mouse clicks.
Compare that to writing a watch file at the moment (assuming one has
to do more than copy and paste the github example).
> > Hm, I can't really think of an example where such a thing couldn't
> > also be implemented in release-monitoring.org.
>
> None of the three use-cases I listed can be done by it AFAICT.
>
> It can't check things that it doesn't have a check for, while
> individual package maintainers in various distros will update their
> packages and Repology will notice the new versions.
Then the maintainer would just have to write a check, just like they
have to do now.
Also, mapping on Repology sometimes needs to be adjusted manually. And
sometimes they disagree and instead tell you to rename the source
package in the distro (happened to me once), which is not really
viable in Debian.
> It presumably doesn't look at the versions for all distros, so it can't
> do the cross-distro VCS snapshot choice check, while individual package
> maintainers in various distros know their packages well and might
> upgrade to a VCS snapshot in their distro, which Repology notices.
Yes it can't, but also I don't think this is something *release
monitoring* should do. It is definitely a good use case and that is
why there is a link to repology on the tracker (called "other
distros"), but it has IMHO nothing to do with *automatic* release
monitoring. Don't get me wrong, I actually like repology exactly for
this particular reason.
> It also isn't going to check locations it doesn't check yet, while
> individual package maintainers in other distros might do that after
> noticing their package hasn't been updated recently and then going
> searching for a new upstream and updating, which Repology notices.
Fair point, but if we would work together on release-monitoring.org
with Fedora, there are more eyes on it as well as in the current
situation.
Repology still has more eyes of course, but then again the link to
Repology is right there on the tracker already if one is curious.
> > Just one quick idea I had: what about a "fake" uscan backend? I.e.
> > something like `Version: release-monitoring.org` in d/watch. In that
> > case uscan will launch an external program that fetches the data from
> > there and gives it back to uscan, so that other tools stay unaffected
> > until a full transition is done.
>
> Excellent idea, that would be great to have.
One more thought on this. If we go with version 5, maybe something like:
Version: 5
Source: release-monitoring.org
Would also work for multiple sources then and in general would fit
nicely to the current idea for v5. It also solves the problem with the
tooling, watch files and uscan would still exist, but the "searching"
portion is offloaded.
> The one issue I can think of with using release-monitoring.org is that
> Debian becomes more reliant on an external service, while currently we
> are completely independent of other distros for version checking.
>
> Converting the release-monitoring.org check to a watch file might be an
> alternative to using it directly that maintains our independence.
Hm right, independence is a valid concern. Anitya itself is open
source [1] so we could host it easily, but of course the real problem
would be the stored data of the projects. I don't know if they are
hosted somewhere, but I'm sure the Fedora guys would be open to share
them with us, so that we could easily spin up a mirror in case there
are any problems (it's probably a good idea to host a read-only mirror
just in case).
This sounds more reasonable to me than writing a tool that converts a
new standard to the old one just as backup.
Regards,
Stephan
[1] https://github.com/fedora-infra/anitya
Reply to: