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 src.fp.org I think being part of a special file in git would be next best.

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

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.

> * Letting people just file a ticket and ask for what they want and >    having the admins would take care of it by editing the repo. This >    would require a separate ticket instance or more programming because >    the tools currently auto-close any ticket they don't understand. > > Anyway, everything is just a simple matter of programming.  Does the > effort required outweigh the annoyance of users having to occasionally > (rarely) submit PRs against a repo that's of nontrivial size?  I don't > know.  Are there any other benefits besides making things a little > easier?  Would having this somehow increase the uptake of monitoring? The effort would be a 1-2 line change in the-new-hotness, and distributing the config to each package repository (some proven packager could do this easily). Given how awful the current approach is from a user perspective, I think this is worth doing. I've Cc'd the hotness maintainer.

- 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 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.

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> 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.

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

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 :)

On Wed, Apr 10, 2019 at 11:04:11AM +0200, Pierre-Yves Chibon wrote: > 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 :) Awesome! Can we have such a plugin to claim orphaned packages as well, please?