Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode
On 6/30/20 1:28 AM, Max Magorsch wrote: > 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? I'd prefer not to scatter tools around anymore. 'Developer' mode sounds better from these two options, but as you already know, I'd prefer showing relevant CI checks for users as well. > > 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'm happy with what you've come up. Can we change the defaults from pkgcheck though? I don't think these 'UnstableOnly' or 'PotentialStable' benefit anyone since they cause a lot of noise, and checking PotentialStable still requires a lot of maintainer attention. I'd like to see them be replaced with 'StableRequestCheck' and 'RedundantVersionCheck' which I believe servers majority of maintainers better. Then obviously the usual CI checks, AbsoluteSymlink, BannedEapiCommand etc what is shown here: https://qa-reports.gentoo.org/output/gentoo-ci/output.html Showing open pull requests would be a **massive** enhancement to developer mode in my opinion. This is the alpha version, right? Looking good so far! Thanks for your work. -- juippis signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode
Hi, On 2020/06/30 16:19, Max Magorsch wrote: > Hi Aaron, > > Thanks for your suggestion. > > On Tue, Jun 30, 2020 at 1:16 AM Aaron Bauman wrote: >> 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? >> > I could imagine packages.g.o to provide different feeds (e.g. about > new releases of package(s) on a per maintainer/project basis). > Following this idea: > > 1. Everyone might directly subscribe to the packages.g.o feeds he is > interested in, to get notified > > 2. We might additionally create a sidecar application which consumes > the feeds and notifies developers/projects. This might be configurable > so that developers and projects can choose the warnings they would > like to receive. This would be great. >> 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. >> > Same goes for your second idea. The sidecar application might also > handle notifications like that in this scenario. > > By splitting this into two applications, packages.g.o would continue > to focus on providing the package data while we might get a second > application which handles all of the notifications. > > What do you think? Anything that'll help avoid the python dependency hell the next time round there are python changes. perl used to be the bane of my existence but for the last few years that dubious honour has gone to python. Not as a developer. As a user. texlive is the other one that annoys me from time to time but an emerge -C $(qlist -IC dev-texlive/*) + remerge generally fixes that. For python that's a death sentence. For that matter, if a CI check gets introduced and one of my packages are now affected this would be helpful too to get a notification, eg, let's say EAPI=6 now gets deprecated, getting a notification that packages x/y for which I'm responsible would be helpful, rather than being caugh off guard when next I bump, or worse, if there is no new version, EAPI=6 just going away completely before I notice. Bad example since EAPI's remain very long past deprecation, but you get the point. Kind Regards, Jaco
Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode
Hi Aaron, Thanks for your suggestion. On Tue, Jun 30, 2020 at 1:16 AM Aaron Bauman wrote: > 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? > I could imagine packages.g.o to provide different feeds (e.g. about new releases of package(s) on a per maintainer/project basis). Following this idea: 1. Everyone might directly subscribe to the packages.g.o feeds he is interested in, to get notified 2. We might additionally create a sidecar application which consumes the feeds and notifies developers/projects. This might be configurable so that developers and projects can choose the warnings they would like to receive. > 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. > Same goes for your second idea. The sidecar application might also handle notifications like that in this scenario. By splitting this into two applications, packages.g.o would continue to focus on providing the package data while we might get a second application which handles all of the notifications. What do you think? -M
Re: [gentoo-dev] RFC: packages.gentoo.org Developer Mode
On June 29, 2020 6:28:30 PM EDT, Max Magorsch 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.
[gentoo-dev] RFC: packages.gentoo.org Developer Mode
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
