On June 29, 2020 6:28:30 PM EDT, Max Magorsch <arz...@gentoo.org> wrote:
>Hi,
>
>Some time ago, the idea of integrating packages.g.o with pkgcheck and
>repology.org came up. There have already been some discussions in bug
>725702 and 725704 regarding this.
>
>The tl;dr is that the packages.g.o backend does now parse both the
>pkgcheck results as well as the repology.org data. Currently, it's
>possible to access them:
> - either by using the new GraphQL API [0]
> - or by using the 'developer mode' in the web interface
>You can enable the developer mode by clicking onto 'Switch to
>Developer Mode' in the footer [1]. Afterwards, you will see pkgcheck
>warnings in the version table as well as warnings in case a new
>version of a package is available according to repology.org (as, e.g.
>currently for x11-wm/xmonad-contrib).
>
>I think, more generally speaking, there is some information that is of
>interest for developers but might not be of interest for regular
>users. This leads to some questions:
>
>1. Would you prefer this information to be displayed in packages.g.o
>using a 'developer mode' or would you prefer a separate application
>similar to the idea of project Grumpy?
>
>2. Is there any further information apart from pkgcheck and repology
>that you would consider useful here for the development workflow?
>
>3. What else would you like to see here? For instance, I could think
>of a configurable dashboard that shows all pkgcheck warnings, new
>versions and open pull requests for packages that a developer
>maintains. Would that be useful? What else could you think of?
>
>I look forward to your opinion.
>
>-M
>
>[0] you can use https://packages.gentoo.org/api/explore/ to get started
>[1] if that's not working, that's likely a caching issue, and the
>javascript assets have to be refreshed
Hi, Max. A couple thoughts... Just let me know if they are too crazy.
1. Could you enable the backend to ping devs/projects via email when a new
release is available for their respective package(s)? Maybe make it optional
for the dev/project to enroll?
2. What about a setting to allow the Python team to deprecate a particular
interpreter then notify respective pkg owners that their ebuild needs updated?
This would possibly workaround the issues mgorny brought up regarding
package.deprecated and noise for CI checks. Also, not sure if this is best
implemented somewhere else first (e.g. pkgcheck) then leveraged by your work.
Just a few quick thoughts...
-Aaron
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
