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

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

 



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

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