Am I the only person that finds this silly?

Infra things aside, is it planned to have this functionality in src.fedoraproject.org?

On a side note, the messages from the-new-hotness still reference pkgdb... Perhaps it should provide a link to: https://pagure.io/releng/fedora-scm-requests/blob/master/f/README.md or https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_...

Other than having it as a direct option in [1]src.fp.org I think being part of a special file in git would be next best.

On Wednesday, 10 April 2019 11:04:11 CEST Pierre-Yves Chibon wrote: > On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote: > > > Other than having it as a direct option in [1]src.fp.org I think being > > part of a special file in git would be next best. > > > In the recent releases pagure grew the possibility to have 3rd party > extensions with their own URL endpoints and able to extend the current > database model to store extra information. > > I've spent a little time using this feature to gain back support in pagure's > UI to toggle the monitoring status. > > Here is a small demo of how it looks like: > http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm > > Basically, there would now be a button on the sidebar which would show the > current monitoring status and would allow project admins and pagure wide > admins to update this setting. > > Feedback most welcome :) > > I'm going to clean up the code a little bit and open a PR on the > pagure-dist-git project, reviews and suggestions welcome there as well. > > Nice! But could it also come with an API endpoint to do this programatically? Like if I want to switch all my monitoring at once in a Python script.

Basically, there would now be a button on the sidebar which would show the current monitoring status and would allow project admins and pagure wide admins to update this setting. Feedback most welcome :)

From: "Pierre-Yves Chibon" <pingou(a)pingoured.fr&gt; To: "Development discussions related to Fedora" <devel(a)lists.fedoraproject.org&gt; Sent: Wednesday, April 10, 2019 11:04:11 AM Subject: Re: Fork a 119MB pagure project to updating monitoring? On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote: > Other than having it as a direct option in [1]src.fp.org I think being > part of a special file in git would be next best. In the recent releases pagure grew the possibility to have 3rd party extensions with their own URL endpoints and able to extend the current database model to store extra information. I've spent a little time using this feature to gain back support in pagure's UI to toggle the monitoring status. Here is a small demo of how it looks like: http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm Basically, there would now be a button on the sidebar which would show the current monitoring status and would allow project admins and pagure wide admins to update this setting. Feedback most welcome :) I'm going to clean up the code a little bit and open a PR on the pagure-dist-git project, reviews and suggestions welcome there as well. Hoping this helps, Pierre _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

>>>> "JC" == Jeremy Cline <jeremy(a)jcline.org&gt; writes:

>>>>> "JC" == Jeremy Cline <jeremy(a)jcline.org&gt; writes: JC> The effort would be a 1-2 line change in the-new-hotness, and JC> distributing the config to each package repository (some proven JC> packager could do this easily). Well that seems easy enough. We still need the repo for the bugzilla assignee override thing, but that's fine. One thing at a time. I can certainly drop commits into the repositories if that's what's needed. We would need to define the name and contents of the file, and the default state for when the file is not present (to perhaps avoid touching every repository). It might also be nice to know what on earth monitoring means for a module or a container, since the fedora-scm-requests has data for them but I don't understand what point it has. We would also need to change the admin tool which is generating these files. I think it would speed up its operation a good bit to not have to mess with this ever-growing repository, so that is a positive. (Especially since the tool does no local caching and so does a full clone each time it processes an SCM request). And fedpkg request-repo would need to drop the --monitor option as it would have no effect. So I guess it's more than just a couple of lines that need to change, but everything outside of the initial new-hotness change and the monitoring file commits could come later. - J<

> > The original idea, I believe, was to allow for the file to different per > > branch without breaking the one branch for all releases that many > > packager like. With modularity and stream branching, the ability to > > say: "I want PR filled for this version to this branch and for that > > version to that branch" would be neat, but this means having per-branch > > information that the-new-hotness will then access and act upon. > > Having this outside of the dist-git repo was meant to make it easier to > > tweak this file and have it diverge without having the different > > dist-git branches diverge. > > If this is the reason than I don't think it's good idea to move the > monitoring file > to package repository, because the-new-hotness doesn't know which branch > should be used. > Right now I'm working on creating PR against dist-git in the-new-hotness, > but this > is basic feature and will create PR only against master branch, it's > than on packager to check, if this is correct. The alternative would be to change the format to include the mapping version -> git branch. If we could do this in a backward compatible way it'd be great but that's always kinda hard. Pierre

On 25/03/19 21:23, Jeremy Cline wrote: > On 3/25/19 1:55 PM, Jason L Tibbitts III wrote: > > > > > > > "KF" == Kevin Fenzi <kevin(a)scrye.com&gt; writes: > > > > KF> Well, I find it unfortunate, does that count? :) > > > > It is unfortunate, but note that it's unfortunate simply because of our > > procedures.  Certainly it would be nice if the functionality for making > > new branches and changing monitoring and some bugzilla settings were > > integrated directly into src.fp.o; I won't argue against that. However, > > that doesn't mean that changing those settings couldn't be accomplished > > via some means other than a PR. > > > > Possibilities I can think of include: > > > > * Doing this via tickets in a manner similar to how branches are > >    requested.  This would require teaching the ticket processing tools > >    how to perform the operation, and writing some tool to submit the > >    request.  Kind of a lot of overhead for a rare operation. > > > > * Just storing this information in the package repository.  I've never > >    understood why the system can't just extract this information from > >    git.  I suspect there must be some reason related to security or > >    resources consumption which prevents services from having a shallow > >    git clone around from which to grab information like this, but > > I'm not > >    sure. > > > > This is how it _should_ work. I just looked at the actual implementation > and hotness is doing an HTTP GET to the scm-requests repository. It > makes no sense, each repo should have a "monitoring" file or something. > From the perspective of hotness, nothing changes. I have no idea why it > was put in a central repository. I started to maintain the-new-hotness few months ago, so I don't know why there is some central repository. I agree with Jeremy that the best option is to have monitoring information directly in package repository.

On 26/03/19 11:36, Pierre-Yves Chibon wrote: > On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote: > > > > On 25/03/19 21:23, Jeremy Cline wrote: > > > On 3/25/19 1:55 PM, Jason L Tibbitts III wrote: > > > > > > > > > "KF" == Kevin Fenzi <kevin(a)scrye.com&gt; writes: > > > > KF> Well, I find it unfortunate, does that count? :) > > > > > > > > It is unfortunate, but note that it's unfortunate simply because of our > > > > procedures.  Certainly it would be nice if the functionality for making > > > > new branches and changing monitoring and some bugzilla settings were > > > > integrated directly into src.fp.o; I won't argue against that. However, > > > > that doesn't mean that changing those settings couldn't be accomplished > > > > via some means other than a PR. > > > > > > > > Possibilities I can think of include: > > > > > > > > * Doing this via tickets in a manner similar to how branches are > > > >    requested.  This would require teaching the ticket processing tools > > > >    how to perform the operation, and writing some tool to submit the > > > >    request.  Kind of a lot of overhead for a rare operation. > > > > > > > > * Just storing this information in the package repository.  I've never > > > >    understood why the system can't just extract this information from > > > >    git.  I suspect there must be some reason related to security or > > > >    resources consumption which prevents services from having a shallow > > > >    git clone around from which to grab information like this, but > > > > I'm not > > > >    sure. > > > > > > > This is how it _should_ work. I just looked at the actual implementation > > > and hotness is doing an HTTP GET to the scm-requests repository. It > > > makes no sense, each repo should have a "monitoring" file or something. > > > From the perspective of hotness, nothing changes. I have no idea why it > > > was put in a central repository. > > I started to maintain the-new-hotness few months ago, so I don't know why > > there is > > some central repository. I agree with Jeremy that the best option is to have > > monitoring > > information directly in package repository. > The original idea, I believe, was to allow for the file to different per branch > without breaking the one branch for all releases that many packager like. > With modularity and stream branching, the ability to say: "I want PR filled for > this version to this branch and for that version to that branch" would be neat, > but this means having per-branch information that the-new-hotness will then > access and act upon. > Having this outside of the dist-git repo was meant to make it easier to tweak > this file and have it diverge without having the different dist-git branches > diverge. If this is the reason than I don't think it's good idea to move the monitoring file to package repository, because the-new-hotness doesn't know which branch should be used. Right now I'm working on creating PR against dist-git in the-new-hotness, but this is basic feature and will create PR only against master branch, it's than on packager to check, if this is correct.

On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote: > On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote: >> >> >> On 25/03/19 21:23, Jeremy Cline wrote: >>> On 3/25/19 1:55 PM, Jason L Tibbitts III wrote: >>>>>>>>> "KF" == Kevin Fenzi <kevin(a)scrye.com&gt; writes: >>>> >>>> KF> Well, I find it unfortunate, does that count? :) >>>> >>>> It is unfortunate, but note that it's unfortunate simply because >>>> of our >>>> procedures.  Certainly it would be nice if the functionality for >>>> making >>>> new branches and changing monitoring and some bugzilla settings were >>>> integrated directly into src.fp.o; I won't argue against that. >>>> However, >>>> that doesn't mean that changing those settings couldn't be >>>> accomplished >>>> via some means other than a PR. >>>> >>>> Possibilities I can think of include: >>>> >>>> * Doing this via tickets in a manner similar to how branches are >>>>     requested.  This would require teaching the ticket processing >>>> tools >>>>     how to perform the operation, and writing some tool to submit the >>>>     request.  Kind of a lot of overhead for a rare operation. >>>> >>>> * Just storing this information in the package repository.  I've >>>> never >>>>     understood why the system can't just extract this information >>>> from >>>>     git.  I suspect there must be some reason related to security or >>>>     resources consumption which prevents services from having a >>>> shallow >>>>     git clone around from which to grab information like this, but >>>> I'm not >>>>     sure. >>>> >>> >>> This is how it _should_ work. I just looked at the actual >>> implementation >>> and hotness is doing an HTTP GET to the scm-requests repository. It >>> makes no sense, each repo should have a "monitoring" file or >>> something. >>>  From the perspective of hotness, nothing changes. I have no idea >>> why it >>> was put in a central repository. >> I started to maintain the-new-hotness few months ago, so I don't >> know why >> there is >> some central repository. I agree with Jeremy that the best option is >> to have >> monitoring >> information directly in package repository. > > The original idea, I believe, was to allow for the file to different > per branch > without breaking the one branch for all releases that many packager > like. That doesn't make sense to me. Are you saying people might want different files per branch, but also only have one branch in their dist- git? Or is this only about the modularity/stream branching thing? > With modularity and stream branching, the ability to say: "I want PR > filled for > this version to this branch and for that version to that branch" > would be neat, > but this means having per-branch information that the-new-hotness > will then > access and act upon. That shouldn't require any configuration at all. hotness knows the new version, and can inspect the branches in dist-git. If the project is marked as following semantic versioning in release-monitoring.org, for example, it can automatically make PRs against any branch with the same X release. The fallback is to always make a PR against master and let the packager cherry-pick as they like. > Having this outside of the dist-git repo was meant to make it easier > to tweak > this file and have it diverge without having the different dist-git > branches > diverge. I think having it outside the repo makes it harder to use in every way. I used to maintained hotness and release-monitoring.org and if you sat me down and told me to turn on monitoring now that pkgdb is gone, I probably wouldn't be able to do it in any reasonable amount of time. The packager experience in this regard went from moderately difficult (you have to know to poke in pkgdb) to downright horrendous.

- Jeremy _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Tue, Mar 26, 2019 at 07:16:24PM +0000, Jeremy Cline wrote: > On 3/26/19 5:36 AM, Pierre-Yves Chibon wrote: >> On Tue, Mar 26, 2019 at 09:37:26AM +0100, Michal Konecny wrote: >>> >>> On 25/03/19 21:23, Jeremy Cline wrote: >>>> On 3/25/19 1:55 PM, Jason L Tibbitts III wrote: >>>>>>>>>> "KF" == Kevin Fenzi <kevin(a)scrye.com&gt; writes: >>>>> KF> Well, I find it unfortunate, does that count? :) >>>>> >>>>> It is unfortunate, but note that it's unfortunate simply because of our >>>>> procedures.  Certainly it would be nice if the functionality for making >>>>> new branches and changing monitoring and some bugzilla settings were >>>>> integrated directly into src.fp.o; I won't argue against that. However, >>>>> that doesn't mean that changing those settings couldn't be accomplished >>>>> via some means other than a PR. >>>>> >>>>> Possibilities I can think of include: >>>>> >>>>> * Doing this via tickets in a manner similar to how branches are >>>>>    requested.  This would require teaching the ticket processing tools >>>>>    how to perform the operation, and writing some tool to submit the >>>>>    request.  Kind of a lot of overhead for a rare operation. >>>>> >>>>> * Just storing this information in the package repository.  I've never >>>>>    understood why the system can't just extract this information from >>>>>    git.  I suspect there must be some reason related to security or >>>>>    resources consumption which prevents services from having a shallow >>>>>    git clone around from which to grab information like this, but >>>>> I'm not >>>>>    sure. >>>>> >>>> This is how it _should_ work. I just looked at the actual implementation >>>> and hotness is doing an HTTP GET to the scm-requests repository. It >>>> makes no sense, each repo should have a "monitoring" file or something. >>>> From the perspective of hotness, nothing changes. I have no idea why it >>>> was put in a central repository. >>> I started to maintain the-new-hotness few months ago, so I don't know why >>> there is >>> some central repository. I agree with Jeremy that the best option is to have >>> monitoring >>> information directly in package repository. >> The original idea, I believe, was to allow for the file to different per branch >> without breaking the one branch for all releases that many packager like. > That doesn't make sense to me. Are you saying people might want > different files per branch, but also only have one branch in their dist- > git? Or is this only about the modularity/stream branching thing? The thought was that people may want different behavior per branch without having different files/content per branch. So the-new-hotness notifies about 0.1 in EPEL and 1.0 in F29 and 2.0 in master. This type of scenario becoming increasingly possible with stream branching.

I'm trying to remember the thought process from back then, I'm not saying it was perfect, that it is still valid nor that we cannot change it, just trying to give some context :) Pierre _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

On Mon, Mar 25, 2019 at 12:27 PM Kevin Fenzi <kevin(a)scrye.com <mailto:kevin@scrye.com>> wrote: Can you file an issue or PR? https://github.com/fedora-infra/the-new-hotness/issues Filed an issue but there were quite a few some going back to 2015... Is it being actively maintained?

Thanks, Richard _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org