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

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

 





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

mkonecny

Pierre
_______________________________________________
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