On Tue, Mar 26, 2019 at 01:33:15PM +0100, Michal Konecny wrote: > > > 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. 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 _______________________________________________ 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
