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

2019-04-12 Thread Pierre-Yves Chibon 
On Thu, Apr 11, 2019 at 08:41:56PM +0200, Till Maas wrote:
> On Wed, Apr 10, 2019 at 11:04:11AM +0200, Pierre-Yves Chibon wrote:
> 
> > Basically, there would now be a button on the sidebar which would show the
> > current monitoring status and would allow project admins and pagure wide 
> > admins
> > to update this setting.
> > 
> > Feedback most welcome :)
> 
> Awesome! Can we have such a plugin to claim orphaned packages as well,
> please?

Should be doable, let me think about it and see what I can come up with :)


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-11 Thread Charalampos Stratakis 


- Original Message -
> From: "Pierre-Yves Chibon" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Wednesday, April 10, 2019 11:04:11 AM
> Subject: Re: Fork a 119MB pagure project to updating monitoring?
> 
> On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote:
> >Other than having it as a direct option in [1]src.fp.org I think being
> >part of a special file in git would be next best.
> 
> In the recent releases pagure grew the possibility to have 3rd party
> extensions
> with their own URL endpoints and able to extend the current database model to
> store extra information.
> 
> I've spent a little time using this feature to gain back support in pagure's
> UI
> to toggle the monitoring status.
> 
> Here is a small demo of how it looks like:
> http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm
> 
> Basically, there would now be a button on the sidebar which would show the
> current monitoring status and would allow project admins and pagure wide
> admins
> to update this setting.
> 
> Feedback most welcome :)
> 
> I'm going to clean up the code a little bit and open a PR on the
> pagure-dist-git
> project, reviews and suggestions welcome there as well.
> 
> 
> Hoping this helps,
> 
> Pierre
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
> 

That is awesome, thanks for that!

-- 
Regards,

Charalampos Stratakis
Software Engineer
Python Maintenance Team, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-11 Thread Till Maas 
On Wed, Apr 10, 2019 at 11:04:11AM +0200, Pierre-Yves Chibon wrote:

> Basically, there would now be a button on the sidebar which would show the
> current monitoring status and would allow project admins and pagure wide 
> admins
> to update this setting.
> 
> Feedback most welcome :)

Awesome! Can we have such a plugin to claim orphaned packages as well,
please?

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-11 Thread Richard Shaw 
On Wed, Apr 10, 2019 at 4:05 AM Pierre-Yves Chibon 
wrote:

> On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote:
> >Other than having it as a direct option in [1]src.fp.org I think
> being
> >part of a special file in git would be next best.
>
> In the recent releases pagure grew the possibility to have 3rd party
> extensions
> with their own URL endpoints and able to extend the current database model
> to
> store extra information.
>
> I've spent a little time using this feature to gain back support in
> pagure's UI
> to toggle the monitoring status.
>
> Here is a small demo of how it looks like:
> http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm
>
> Basically, there would now be a button on the sidebar which would show the
> current monitoring status and would allow project admins and pagure wide
> admins
> to update this setting.
>
> Feedback most welcome :)
>
> I'm going to clean up the code a little bit and open a PR on the
> pagure-dist-git
> project, reviews and suggestions welcome there as well.
>

Nice work! Looks like it is exactly what I was thinking.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-10 Thread Pierre-Yves Chibon 
On Wed, Apr 10, 2019 at 02:45:48PM +0200, Robert-André Mauchin wrote:
> On Wednesday, 10 April 2019 11:04:11 CEST Pierre-Yves Chibon wrote:
> > On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote:
> > 
> > >Other than having it as a direct option in [1]src.fp.org I think being
> > >part of a special file in git would be next best.
> > 
> > 
> > In the recent releases pagure grew the possibility to have 3rd party
> > extensions
>  with their own URL endpoints and able to extend the current
> > database model to store extra information.
> > 
> > I've spent a little time using this feature to gain back support in pagure's
> > UI
>  to toggle the monitoring status.
> > 
> > Here is a small demo of how it looks like:
> > http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm
> > 
> > Basically, there would now be a button on the sidebar which would show the
> > current monitoring status and would allow project admins and pagure wide
> > admins
>  to update this setting.
> > 
> > Feedback most welcome :)
> > 
> > I'm going to clean up the code a little bit and open a PR on the
> > pagure-dist-git
>  project, reviews and suggestions welcome there as well.
> > 
> > 
> 
> Nice! But could it also come with an API endpoint to do this programatically?
> Like if I want to switch all my monitoring at once in a Python script.

That's how the button works, it calls on to the API endpoint, which is the one
of the tab you can see in the demo :)
The only thing is figuring out the discoverability of that this API endpoint
since it's not part of pagure itself.
For the moment it may end up being in the upstream doc only, I'll see if I can
find something better.


Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-10 Thread Robert-André Mauchin 
On Wednesday, 10 April 2019 11:04:11 CEST Pierre-Yves Chibon wrote:
> On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote:
> 
> >Other than having it as a direct option in [1]src.fp.org I think being
> >part of a special file in git would be next best.
> 
> 
> In the recent releases pagure grew the possibility to have 3rd party
> extensions
 with their own URL endpoints and able to extend the current
> database model to store extra information.
> 
> I've spent a little time using this feature to gain back support in pagure's
> UI
 to toggle the monitoring status.
> 
> Here is a small demo of how it looks like:
> http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm
> 
> Basically, there would now be a button on the sidebar which would show the
> current monitoring status and would allow project admins and pagure wide
> admins
 to update this setting.
> 
> Feedback most welcome :)
> 
> I'm going to clean up the code a little bit and open a PR on the
> pagure-dist-git
 project, reviews and suggestions welcome there as well.
> 
> 

Nice! But could it also come with an API endpoint to do this programatically?
Like if I want to switch all my monitoring at once in a Python script.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-10 Thread Pierre-Yves Chibon 
On Mon, Mar 25, 2019 at 02:55:23PM -0500, Richard Shaw wrote:
>Other than having it as a direct option in [1]src.fp.org I think being
>part of a special file in git would be next best.

In the recent releases pagure grew the possibility to have 3rd party extensions
with their own URL endpoints and able to extend the current database model to
store extra information.

I've spent a little time using this feature to gain back support in pagure's UI
to toggle the monitoring status.

Here is a small demo of how it looks like:
http://ambre.pingoured.fr/public/Screencast_pagure_distgit_anitya.webm

Basically, there would now be a button on the sidebar which would show the
current monitoring status and would allow project admins and pagure wide admins
to update this setting.

Feedback most welcome :)

I'm going to clean up the code a little bit and open a PR on the pagure-dist-git
project, reviews and suggestions welcome there as well.


Hoping this helps,

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-04-08 Thread Robert-André Mauchin 
On Monday, 25 March 2019 21:45:06 CEST Jason L Tibbitts III wrote:
> > "JC" == Jeremy Cline  writes:
> 
> 
> JC> The effort would be a 1-2 line change in the-new-hotness, and
> JC> distributing the config to each package repository (some proven
> JC> packager could do this easily).
> 
> Well that seems easy enough.  We still need the repo for the bugzilla
> assignee override thing, but that's fine.  One thing at a time.
> 
> I can certainly drop commits into the repositories if that's what's
> needed.  We would need to define the name and contents of the file, and
> the default state for when the file is not present (to perhaps avoid
> touching every repository).
> 
> It might also be nice to know what on earth monitoring means for a
> module or a container, since the fedora-scm-requests has data for them
> but I don't understand what point it has.
> 
> We would also need to change the admin tool which is generating these
> files.  I think it would speed up its operation a good bit to not have
> to mess with this ever-growing repository, so that is a positive.
> (Especially since the tool does no local caching and so does a full
> clone each time it processes an SCM request).  And fedpkg request-repo
> would need to drop the --monitor option as it would have no effect.
> 
> So I guess it's more than just a couple of lines that need to change,
> but everything outside of the initial new-hotness change and the
> monitoring file commits could come later.
> 
>  - J<

Any chance this might happen?

 - A YAML (or TOML maybe) file at the root of the dist-git repo
 - name to be determined
 - the-new-hotness can look directly at the file and acts accordingly
 - some "fedpkg set-monitoring [no-monitoring,monitoring,monitoring-with-
scratch]" does the creation and commit of the file
 - --monitor is retired from fedpkg  request-repo
 - Make monitoring an opt-out only (that is we force all maintainers to run 
the commands fedpkg set-monitoring no-monitoring after the change if they 
really want to)

No idea what is the admin tool or what does it do.

On Tuesday, 26 March 2019 14:53:10 CEST Pierre-Yves Chibon wrote:
> > > 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

Could we start simple and add a layer of complexity later on?
Could we keep all the infos in a single file in the master branch? 

I guess everyone is ENOTIME, but it would be great to see that issue progress.

Best regards,

Robert-André



___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-27 Thread Michal Konecny 



On 27/03/19 09:59, Pierre-Yves Chibon wrote:

On Tue, Mar 26, 2019 at 07:16:24PM +, 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  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 don't think the-new-hotness does anything like this. It just files the 
issue in Bugzilla that new version is out.


Michal


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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-27 Thread Pierre-Yves Chibon 
On Tue, Mar 26, 2019 at 07:16:24PM +, 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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-27 Thread Michal Konecny 



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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Jeremy Cline 

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

- Jeremy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Jeremy Cline 

On 3/25/19 3:45 PM, Jason L Tibbitts III wrote:

"JC" == Jeremy Cline  writes:


JC> The effort would be a 1-2 line change in the-new-hotness, and
JC> distributing the config to each package repository (some proven
JC> packager could do this easily).

Well that seems easy enough.  We still need the repo for the bugzilla
assignee override thing, but that's fine.  One thing at a time.

I can certainly drop commits into the repositories if that's what's
needed.  We would need to define the name and contents of the file, and
the default state for when the file is not present (to perhaps avoid
touching every repository).

It might also be nice to know what on earth monitoring means for a
module or a container, since the fedora-scm-requests has data for them
but I don't understand what point it has.



As far as I know monitoring on modules or containers are meaningless.


We would also need to change the admin tool which is generating these
files.  I think it would speed up its operation a good bit to not have
to mess with this ever-growing repository, so that is a positive.
(Especially since the tool does no local caching and so does a full
clone each time it processes an SCM request).  And fedpkg request-repo
would need to drop the --monitor option as it would have no effect.


Indeed, I wasn't aware of all those tools and their integration.

- Jeremy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Pierre-Yves Chibon 
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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Michal Konecny 



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  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Pierre-Yves Chibon 
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  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.

Pierre
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Michal Konecny 



On 25/03/19 21:23, Jeremy Cline wrote:

On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:

"KF" == Kevin Fenzi  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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-26 Thread Michal Konecny 



On 25/03/19 20:58, Richard Shaw wrote:
On Mon, Mar 25, 2019 at 12:27 PM Kevin Fenzi > wrote:



Can you file an issue or PR?
https://github.com/fedora-infra/the-new-hotness/issues


Filed an issue but there were quite a few some going back to 2015... 
Is it being actively maintained?

Yes, it is now, but it was not actively maintained for some time.

mkonecny


Thanks,
Richard


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Jason L Tibbitts III 
> "JC" == Jeremy Cline  writes:

JC> The effort would be a 1-2 line change in the-new-hotness, and
JC> distributing the config to each package repository (some proven
JC> packager could do this easily).

Well that seems easy enough.  We still need the repo for the bugzilla
assignee override thing, but that's fine.  One thing at a time.

I can certainly drop commits into the repositories if that's what's
needed.  We would need to define the name and contents of the file, and
the default state for when the file is not present (to perhaps avoid
touching every repository).

It might also be nice to know what on earth monitoring means for a
module or a container, since the fedora-scm-requests has data for them
but I don't understand what point it has.

We would also need to change the admin tool which is generating these
files.  I think it would speed up its operation a good bit to not have
to mess with this ever-growing repository, so that is a positive.
(Especially since the tool does no local caching and so does a full
clone each time it processes an SCM request).  And fedpkg request-repo
would need to drop the --monitor option as it would have no effect.

So I guess it's more than just a couple of lines that need to change,
but everything outside of the initial new-hotness change and the
monitoring file commits could come later.

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Jeremy Cline 

On 3/25/19 1:55 PM, Jason L Tibbitts III wrote:

"KF" == Kevin Fenzi  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.


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

- Jeremy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Fabio Valentini 
On Mon, Mar 25, 2019 at 8:56 PM Richard Shaw  wrote:
>
> Other than having it as a direct option in src.fp.org I think being part of a 
> special file in git would be next best.

Accessing such a simple file (probably YAML? it seems to be en vogue
right now ...) should be straightforward too, since pagure can serve
raw files from git over plain http, with links like this:
https://src.fedoraproject.org/rpms/rpm/raw/master/f/rpm.spec

Fabio

> Thanks,
> Richard
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 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@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Richard Shaw 
On Mon, Mar 25, 2019 at 12:27 PM Kevin Fenzi  wrote:

>
> Can you file an issue or PR?
> https://github.com/fedora-infra/the-new-hotness/issues


Filed an issue but there were quite a few some going back to 2015... Is it
being actively maintained?

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Richard Shaw 
Other than having it as a direct option in src.fp.org I think being part of
a special file in git would be next best.

Thanks,
Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Jason L Tibbitts III 
> "KF" == Kevin Fenzi  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.

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

 - J<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org

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

2019-03-25 Thread Kevin Fenzi 
On 3/20/19 7:27 AM, Richard Shaw wrote:
> Am I the only person that finds this silly?

Well, I find it unfortunate, does that count? :)

> Infra things aside, is it planned to have this functionality in
> src.fedoraproject.org?

Not that I know of. The problem is that src.fedoraproject.org is a
pagure instance. pagure upstream wants to not carry a bunch of fedora
specific stuff in it if it can avoid it. So, I don't know that anyone
has convinced them to carry something like this.

Another option might be to put it in FPDC, but that is somewhat up in
the air too.

I agree we should "fix" this, but it's unclear what the best fix is.

> On a side note, the messages from the-new-hotness still reference pkgdb...
> Perhaps it should provide a link to:
> 
> https://pagure.io/releng/fedora-scm-requests/blob/master/f/README.md
>
> or
> 
> https://fedoraproject.org/wiki/Infrastructure/WhatHappenedToPkgdb#How_do_I_change_the_upstream-monitoring.2Fanitya_flag_for_my_packages.3F

Can you file an issue or PR?
https://github.com/fedora-infra/the-new-hotness/issues

kevin



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org