Hey, I'm opening this up for discussion. It'd be interesting to integrate packages.gentoo.org with some of the pkgcheck checks, like showing results for StableRequestCheck and RedundantVersionCheck per package. There are probably a lot more that could be shown, for example some relevant QA notices perhaps? This was suggested by mgorny so who I'm adding as CC for more ideas.
I added a link to CI in the Resources section; this is the simplest integration to do and it was straightforward. I think the main issue is that you have two sets of users: - Anonymous users who want package data. - Developers who want some kind of status page for their work. The typical way this is done is to only show the QA data to logged in users who we think want to see it. So for example in gitlab / github extra data is shown to the repo owner (like outdated deps, security problems, etc.) This data is not typically show to logged in users who are viewing the repo. I'm also not aware of an API interface for pkgcheck output; at best I'd need some uri to consume for a given CPV that listed any violations in some kind of interchange format (json, xml, whatever.) -A
That's a nice initiative, thanks! Honestly I assumed there was some fast way to query the xml output _only_ showing info per package. Loading that large file is quite slow. I believe StableRequestCheck would be beneficial to show for everyone - to every user. It works like this: § pkgcheck --color true scan "mycategory/mypackage" -c StableRequestCheck -R FormatReporter --format 'stabilize {category}/{package}-{version} # {desc}' stabilize app-emulation/lxc-3.1.0-r1 # slot(0) no change in 230 days for unstable keywords: [ ~amd64, ~ppc64, ~x86 ] stabilize app-emulation/lxd-3.16-r1 # slot(0) no change in 170 days for unstable keyword: [ ~amd64 ] stabilize media-libs/rlottie-0.0.1_pre20200424 # slot(0) no change in 30 days for unstable keywords: [ ~amd64, ~x86 ] Any user, stable user, would see when a new version is a potential stable candidate and _could_ ask for stabilization, taking burden off from maintainers who may be running ~ and not caring about stable so much. It'd also signal our proxied maintainers when is a good time to ask for stabilization - it's a common question. And why not signal it to devs as well who may be looking at their own packages. I could see something like this existing in the web page: https://dev.gentoo.org/~juippis/pics/pgo_stable_candidate.png (with text and tooltip) Downside is, StableRequestCheck is not enabled on the qa-reports site. Not even on verbose check. So it'd be have to be ran and cached somewhere else. Also when you update cache, pkgcheck scan calls become rather instant - maybe it would be possible to just call pkgcheck scan when loading the page? Although I believe parsing the output.xml file is a better solution. This could be generated once a day. I do find it annoying that CI results are split. Ideally we'd put StableRequestCheck and RedundantVersionCheck to the verbose-output.xml, and query it locally per-package to p.g.o output. (Or maybe https loading in infra web is faster)
(In reply to Joonas Niilola from comment #2) > That's a nice initiative, thanks! Honestly I assumed there was some fast way > to query the xml output _only_ showing info per package. Loading that large > file is quite slow. So for production my thought was to basically: - Build a second updater job in p.g.o that runs pkgcheck. - The updater would populate some additional p.g.o tables. - p.g.o would optionally show this data somehow. I'd need a stronger set of user stories around p.g.o though. I think the story you detail below is a great story...but probably not for p.g.o. I think we could like do more requirements gathering and build that tool pretty easily though. > > I believe StableRequestCheck would be beneficial to show for everyone - to > every user. It works like this: > > § pkgcheck --color true scan "mycategory/mypackage" -c StableRequestCheck > -R FormatReporter --format 'stabilize {category}/{package}-{version} # > {desc}' > > stabilize app-emulation/lxc-3.1.0-r1 # slot(0) no change in 230 days for > unstable keywords: [ ~amd64, ~ppc64, ~x86 ] > > stabilize app-emulation/lxd-3.16-r1 # slot(0) no change in 170 days for > unstable keyword: [ ~amd64 ] > > stabilize media-libs/rlottie-0.0.1_pre20200424 # slot(0) no change in 30 > days for unstable keywords: [ ~amd64, ~x86 ] > > Any user, stable user, would see when a new version is a potential stable > candidate and _could_ ask for stabilization, taking burden off from > maintainers who may be running ~ and not caring about stable so much. It'd > also signal our proxied maintainers when is a good time to ask for > stabilization - it's a common question. And why not signal it to devs as > well who may be looking at their own packages. I could see something like > this existing in the web page: > https://dev.gentoo.org/~juippis/pics/pgo_stable_candidate.png (with text > and tooltip) So I want to unpack this more. For maintainers, tools exist already for this sort of thing; both in pkgcheck as well as older tools (imlate comes to mind as a similar tool.) So to me I can see three approaches here: - The tools are insufficient, and we should add a new tool. Since we are using pkgcheck to generate this data; that seems unlikely. The tool exists now! - The tools are unused, e.g. not everyone knows about the tool or runs it regularly, so the reports are not seen. - The tools are used, but maintainers are busy and so they have not done the stabilization. If our goal is to get the maintainer to do a stabilization, I think we can just write an application that can surface these automatically. For example we could run pkgcheck, parse the output, and file bugs for potential stabilization. Imagine if we wrote something like that: - Its open source, +RW @scrappy-app-dev-team - Its config is +RW @devs. - Developers can configure the behavior on a per-maintainer basis (depending on maintainer type.) - Developers who hate the tool can turn it off by modifying the public config so it doesn't auto-file bugs for their packages. > > Downside is, StableRequestCheck is not enabled on the qa-reports site. Not > even on verbose check. So it'd be have to be ran and cached somewhere else. > Also when you update cache, pkgcheck scan calls become rather instant - > maybe it would be possible to just call pkgcheck scan when loading the page? > Although I believe parsing the output.xml file is a better solution. This > could be generated once a day. > > I do find it annoying that CI results are split. Ideally we'd put > StableRequestCheck and RedundantVersionCheck to the verbose-output.xml, and > query it locally per-package to p.g.o output. (Or maybe https loading in > infra web is faster)
This has been implemented some time ago. Thus I'm going to close this bug. Thanks again for the suggestion.
