On 26/03/19 20:16, 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@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.
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.
Speaking about this, I should take these packages from you to ease your
burden. :-)
- 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
