Re: Fork a 119MB pagure project to updating monitoring?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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

* 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.
From the-new-hotness perspective this should be pretty easy to do, like
Jeremy said it is only change of the current fedora-scm-requests url to src.fp.o
url.

mkonecny

- Jeremy
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux