Re: packages app
On 7/28/20 5:33 AM, Miroslav Suchý wrote: >>> Will be people ok with the speed? >> I don't understand exactly what you are referring to here. If you mean >> the speed of search, > I meant the speed of update of Google index. Google doesn't say how long it takes them to index. Assuming we submit the sitemap to Google, hopefully the initial index shouldn't be more than a few weeks. We can set the page description to the package description so that constant crawls aren't necessary. > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
Dne 28. 07. 20 v 1:18 Brendan Early napsal(a): > How are you getting the data in ng?! From a clean state on my computer, The code remained unchanged. The most time the code spend quering PDC. Here: https://github.com/xsuchy/fedora-packages-ng/blob/master/fedoracommunity/search/index.py#L212 > it takes packages-static around 140 seconds to get the package metadata > into the db and about 195 seconds to generate all the static pages. >> How much data it consumes?> Not anything monumental, just ~6.3G. Nice. >> Will be people ok with the speed? > I don't understand exactly what you are referring to here. If you mean > the speed of search, I meant the speed of update of Google index. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
On 7/27/20 9:40 AM, Miroslav Suchý wrote: > Dne 16. 07. 20 v 21:56 Brendan Early napsal(a): >> and would time out if an external service took too long to respond. > Only if you wanted to list builds, bugs the overview page is more or less > static (i.e. it is rendered just from > local DB). I was basing that statement off of a quick skim of old fedora packages source. I may be mistaken as I'm still new to python, but I was under the impression that it always queried koji when it was given a request. https://github.com/fedora-infra/fedora-packages/blob/master/fedoracommunity/widgets/package/overview.py#L50-L57 > Fedora-packages-static does not list them at all. This is ok when we agree > that this is what people find > sufficient. This is intentional, I can easily write some client-side JS to add that functionality if it is needed. https://pagure.io/fedora-packages-static/pull-request/1#comment-0 > What I am curious about fedora-packages-static - how long it takes to > generate all those pages? When I tried to retrieve > initial data fedora-packages-ng, it took several hours. Which may be too much > for daily job. How are you getting the data in ng?! From a clean state on my computer, it takes packages-static around 140 seconds to get the package metadata into the db and about 195 seconds to generate all the static pages. > How much data it consumes? Not anything monumental, just ~6.3G. > What is yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org? A staging YaCy server that Timothée had on communishift. https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/message/4PE4YQ4SGRCA3JIMFKRBMLR7CXDC45GT/ > Or when we delegate search to Google, how long it > takes to refresh the search index? I have code to generate sitemaps, which can be used to tell Google how often we want to be crawled and it will make sure every page is indexed. This should improve discoverability, I don't know how well the old one was indexed. > Will be people ok with the speed? I don't understand exactly what you are referring to here. If you mean the speed of search, I don't specifically know about the speed of Solr. In the event hosting something ourselves does not work out we could always go with Algolia, which is near-instant. signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
On Tue, Jul 21, 2020 at 04:14:39PM -0500, Brendan Early wrote: > > I didn't realize at the time that there were two solutions being > developed. Timothée was giving lots of status updates and you and > Clement were active in those discussions, so it wasn't very obvious from > my point of view as a fairly new contributor here. I don't know if it's > possible to merge the two. I don't see the point of spitting the > functionality as they mostly do the same thing. Right. I'm happy for any good solution...I wasn't aware that msuchy was working on a replacement (other than just saying he would if he found time) until he appeared with the initial project. ;) kevin -- > > > Brendan Early > > > > > kevin > > -- > >> Pagure: https://pagure.io/fedora-packages-static > >> > >> -- > >> > >> Brendan Early > >> > >> On 7/16/20 12:06 PM, Kevin Fenzi wrote: > >>> So, I think we have two groups approaching a replacement app for > >>> packages? > >>> > >>> Can we perhaps decide which way we want to go and look at deploying > >>> something soon? This has been more important since we didn't move the > >>> old broken packages app from the old datacenter and people keep asking > >>> about it. > >>> > >>> We could wait until we have staging back, but I don't think we need to > >>> wait for that to decide what we want to do here? > >>> > >>> Thoughts? > >>> > >>> kevin > >>> > >>> ___ > >>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org > >>> To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > >>> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >>> List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > >> ___ > >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org > >> To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > >> Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > >> List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > > > > ___ > > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > -BEGIN PGP SIGNATURE- > > iQIzBAEBCAAdFiEEEuO7QAvcjGvjf8zLJc9/feL/WqkFAl8XWqsACgkQJc9/feL/ > WqmQgA/+Lki6d5XZjItBp9k8jtapnaaCPQkClYbZ+j1WE51onGhktD89x9LE/GtJ > WAqdbEdMRcgJPMAtOiYAQzlWXwny6qvODw+XoOqFf0Zp5VyAeOkxyhczdLDguP7N > NYoWUj86S0QK+SFZyKMin8ExD9tnICIX/e9J9UCKNmDGxvMADtm3A5iO3LRxOaN4 > 8Ko+S3EE4FujBDpIN/+WMZbCSXKU4j1N2KD2tPXaeimzyKCShFXXggGc4kAsJI0/ > xsCJNl8WO7gZ/8kw/hjZU17q+l68LR4e01+/OBEsHZhCVbxG/RGkNsXIA2UBYF4A > sH7mibpgFcULJr+5fhPjgyRTeTl5dFK6Wy2ikneNzDH3v44DT34Y1OaWyvdnaSuE > gz0+ouZ9UOYKNPxi3kysDZkPj9A+n/Oq0Hze2c5CP1gtkROUzjpQdDeO/0Qy9upu > Kt3VjkqMB320OVCdHrbLhhiirazePWxOoQnFBwIrkyRGVKrIrYhQQmpVwxcIwp3Y > MW2xlPphqRkpzaVkblkTBQ5rQdFJc4B3X04q3u2+su48TMztFoEzQRC0U1DTRK2Q > c+Q8crkE9Tvt25Y2OyIADPABUnVwhtXFxRZCrVemWy87kGxNY0Uf7lHJ+RQyZjst > B69+We2MlU47Vw0KWMeIPbKn65J3YYG7jzlKY2Qe/1aH8/VUUzY= > =hbr0 > -END PGP SIGNATURE- > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
Dne 16. 07. 20 v 21:56 Brendan Early napsal(a): > and would time out if an external service took too long to respond. Only if you wanted to list builds, bugs the overview page is more or less static (i.e. it is rendered just from local DB). Fedora-packages-static does not list them at all. This is ok when we agree that this is what people find sufficient. What I am curious about fedora-packages-static - how long it takes to generate all those pages? When I tried to retrieve initial data fedora-packages-ng, it took several hours. Which may be too much for daily job. How much data it consumes? What is yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org? Or when we delegate search to Google, how long it takes to refresh the search index? Will be people ok with the speed? -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 7/17/20 6:40 PM, Kevin Fenzi wrote: > On Thu, Jul 16, 2020 at 02:56:08PM -0500, Brendan Early wrote: >> Hi, >> >> Timothée and I are working on fedora-packages-static. It's a lot simpler >> than the old packages app, it just generates static files that you can >> serve. The old packages app was missing packages and would time out if >> an external service took too long to respond. This approach eliminates >> those problems by not having the web server do that work on demand. >> Because these are just static files, search will need to be managed by >> something else (E.g. YaCy, Algolia). I have generated an example page >> and put a link below. >> >> >> Example: >> https://mymindstorm.fedorapeople.org/pkgs-demo/pkgs/numix-icon-theme-square/ > Yeah, and msuchy (and others) have been working on: > https://github.com/xsuchy/fedora-packages-ng > > My point is that we shouldn't have 2 groups working on the replacement, > that seems like it's taking time from one group we don't decide to use > the app from. Or is there a possibily to merge the two apps or split the > functionality up so both are complementary? I didn't realize at the time that there were two solutions being developed. Timothée was giving lots of status updates and you and Clement were active in those discussions, so it wasn't very obvious from my point of view as a fairly new contributor here. I don't know if it's possible to merge the two. I don't see the point of spitting the functionality as they mostly do the same thing. Brendan Early > > kevin > -- >> Pagure: https://pagure.io/fedora-packages-static >> >> -- >> >> Brendan Early >> >> On 7/16/20 12:06 PM, Kevin Fenzi wrote: >>> So, I think we have two groups approaching a replacement app for >>> packages? >>> >>> Can we perhaps decide which way we want to go and look at deploying >>> something soon? This has been more important since we didn't move the >>> old broken packages app from the old datacenter and people keep asking >>> about it. >>> >>> We could wait until we have staging back, but I don't think we need to >>> wait for that to decide what we want to do here? >>> >>> Thoughts? >>> >>> kevin >>> >>> ___ >>> infrastructure mailing list -- infrastructure@lists.fedoraproject.org >>> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org >>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >>> List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org >> ___ >> infrastructure mailing list -- infrastructure@lists.fedoraproject.org >> To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org >> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEEuO7QAvcjGvjf8zLJc9/feL/WqkFAl8XWqsACgkQJc9/feL/ WqmQgA/+Lki6d5XZjItBp9k8jtapnaaCPQkClYbZ+j1WE51onGhktD89x9LE/GtJ WAqdbEdMRcgJPMAtOiYAQzlWXwny6qvODw+XoOqFf0Zp5VyAeOkxyhczdLDguP7N NYoWUj86S0QK+SFZyKMin8ExD9tnICIX/e9J9UCKNmDGxvMADtm3A5iO3LRxOaN4 8Ko+S3EE4FujBDpIN/+WMZbCSXKU4j1N2KD2tPXaeimzyKCShFXXggGc4kAsJI0/ xsCJNl8WO7gZ/8kw/hjZU17q+l68LR4e01+/OBEsHZhCVbxG/RGkNsXIA2UBYF4A sH7mibpgFcULJr+5fhPjgyRTeTl5dFK6Wy2ikneNzDH3v44DT34Y1OaWyvdnaSuE gz0+ouZ9UOYKNPxi3kysDZkPj9A+n/Oq0Hze2c5CP1gtkROUzjpQdDeO/0Qy9upu Kt3VjkqMB320OVCdHrbLhhiirazePWxOoQnFBwIrkyRGVKrIrYhQQmpVwxcIwp3Y MW2xlPphqRkpzaVkblkTBQ5rQdFJc4B3X04q3u2+su48TMztFoEzQRC0U1DTRK2Q c+Q8crkE9Tvt25Y2OyIADPABUnVwhtXFxRZCrVemWy87kGxNY0Uf7lHJ+RQyZjst B69+We2MlU47Vw0KWMeIPbKn65J3YYG7jzlKY2Qe/1aH8/VUUzY= =hbr0 -END PGP SIGNATURE- ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
On Thu, Jul 16, 2020 at 02:56:08PM -0500, Brendan Early wrote: > Hi, > > Timothée and I are working on fedora-packages-static. It's a lot simpler > than the old packages app, it just generates static files that you can > serve. The old packages app was missing packages and would time out if > an external service took too long to respond. This approach eliminates > those problems by not having the web server do that work on demand. > Because these are just static files, search will need to be managed by > something else (E.g. YaCy, Algolia). I have generated an example page > and put a link below. > > > Example: > https://mymindstorm.fedorapeople.org/pkgs-demo/pkgs/numix-icon-theme-square/ Yeah, and msuchy (and others) have been working on: https://github.com/xsuchy/fedora-packages-ng My point is that we shouldn't have 2 groups working on the replacement, that seems like it's taking time from one group we don't decide to use the app from. Or is there a possibily to merge the two apps or split the functionality up so both are complementary? kevin -- > > Pagure: https://pagure.io/fedora-packages-static > > -- > > Brendan Early > > On 7/16/20 12:06 PM, Kevin Fenzi wrote: > > So, I think we have two groups approaching a replacement app for > > packages? > > > > Can we perhaps decide which way we want to go and look at deploying > > something soon? This has been more important since we didn't move the > > old broken packages app from the old datacenter and people keep asking > > about it. > > > > We could wait until we have staging back, but I don't think we need to > > wait for that to decide what we want to do here? > > > > Thoughts? > > > > kevin > > > > ___ > > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: packages app
Hi, Timothée and I are working on fedora-packages-static. It's a lot simpler than the old packages app, it just generates static files that you can serve. The old packages app was missing packages and would time out if an external service took too long to respond. This approach eliminates those problems by not having the web server do that work on demand. Because these are just static files, search will need to be managed by something else (E.g. YaCy, Algolia). I have generated an example page and put a link below. Example: https://mymindstorm.fedorapeople.org/pkgs-demo/pkgs/numix-icon-theme-square/ Pagure: https://pagure.io/fedora-packages-static -- Brendan Early On 7/16/20 12:06 PM, Kevin Fenzi wrote: > So, I think we have two groups approaching a replacement app for > packages? > > Can we perhaps decide which way we want to go and look at deploying > something soon? This has been more important since we didn't move the > old broken packages app from the old datacenter and people keep asking > about it. > > We could wait until we have staging back, but I don't think we need to > wait for that to decide what we want to do here? > > Thoughts? > > kevin > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
packages app
So, I think we have two groups approaching a replacement app for packages? Can we perhaps decide which way we want to go and look at deploying something soon? This has been more important since we didn't move the old broken packages app from the old datacenter and people keep asking about it. We could wait until we have staging back, but I don't think we need to wait for that to decide what we want to do here? Thoughts? kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Wed, 22 Apr 2020 at 11:18, Timothée Floure wrote: > Hi, > > Took a bit more time than expected due to other and more local > priorities on my side. The basic structure is there and usable, and > indexing seemed work quite well before CommunityShift (hence yacy) went > down. > > * Main page: https://fnux.ch/fedpkg/public_html/ > * Crawler entrypoint: > https://fnux.ch/fedpkg/public_html/crawler-entrypoint.html > * Package page: > https://fnux.ch/fedpkg/public_html/pkgs/qutebrowser/ > > Everything lives on https://pagure.io/fedora-packages-static, and > contains the TODO-list (epel-8, flatpaks & containers, dependencies, > etc.). CommunityShift will be back earlier than I initially thought, > and I hope to find some time to complete some of the TODO tasks by then. > This is cool, thanks for working on this. How long does it take for the `make all` command to complete ? ( I am just curious compared to the current solution :-) ) > > Feedback, green light, whether it looks good enough to replace the > current app, or anything you think relevant is welcome. The only > dependencies are python3-requests and python3-jinja2 and there is no > flying parts since it is a static website: we should not hit dead > dependency issues ever again (or the package app will be the least of > our problems!). > I think we should look at deploying this service once communishift is back online. Also since the current application will go down during the data center move switching to this service instead of bringing back up the old code base seems to me like an interesting way forward. > > Have a nice day, > > -- > Timothée > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Hi, Took a bit more time than expected due to other and more local priorities on my side. The basic structure is there and usable, and indexing seemed work quite well before CommunityShift (hence yacy) went down. * Main page: https://fnux.ch/fedpkg/public_html/ * Crawler entrypoint: https://fnux.ch/fedpkg/public_html/crawler-entrypoint.html * Package page: https://fnux.ch/fedpkg/public_html/pkgs/qutebrowser/ Everything lives on https://pagure.io/fedora-packages-static, and contains the TODO-list (epel-8, flatpaks & containers, dependencies, etc.). CommunityShift will be back earlier than I initially thought, and I hope to find some time to complete some of the TODO tasks by then. Feedback, green light, whether it looks good enough to replace the current app, or anything you think relevant is welcome. The only dependencies are python3-requests and python3-jinja2 and there is no flying parts since it is a static website: we should not hit dead dependency issues ever again (or the package app will be the least of our problems!). Have a nice day, -- Timothée signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Thu, Apr 09, 2020 at 01:39:47PM +0200, Timothée Floure wrote: > I still need to handle a few cases (e.g. subpackages) but everything > looks good so far. Generating the whole static website is quite fast > (minutes including repository metadata sync, seconds otherwise). > > Screenshot attached :-) Nice. starting to look good. ;) > I should have something usable by next week. If I were to deploy it > somewhere, would it be in communityshift (= container)? When is > communityshift supposed to come back online? Yeah, that would be a nice place for it. It goes down monday and back up in a few weeks (depends on how long it takes to ship and rack up and bring back up). > Would it be possible to allocate the pkg.fedoraproject.org domain for > this service? I think that would be confusing. We have pkgs.fedoraproject.org (which is the ssh hostname for src.fedoraproject.org), so pkg would be pretty confusing to them. I think packages is even confusing too. But I'm not sure what (if anything) would be less confusing... debian uses 'packages' also, FWIW. > If there is no server space available due to the datacenter move, I'm > pretty sure I can ask $DAYJOB (https://datacenterlight.ch/) to sponsor a > VM for the next few months (against a mention in footer or similar). Cool. Well, communishift should be back before too long... kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
I started to work here: https://pagure.io/fedora-packages-static/tree/master I'll update you once I get something usable. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Mon, 6 Apr 2020 at 08:58, Timothée Floure wrote: > Hi, > > > How does the indexing works ? > > You point Yacy to a domain or list of URLs > (https://fnux.fedorapeople.org/pkgs/ in this case), and it takes care of > everything. There is also an advanced crawler panel in the UI allowing > you to filter content (e.g. HTML classes) from pages, which would be > useful if we do not want to index everything (e.g. dependencies). > > I am not familiar with the maths used by Yacy for indexing. > Me neither :D > > > And what would it take to add more info for each package ? > > I wrote a quick script (https://paste.gnugen.ch/raw/4JAC) fetching > package metadata from PDC+mdapi for testing, but it is ways too slow to > scale to the whole package set. > Cool, yeah the current indexing takes hours (I think around 4-5 hours) there are more than 80 000s packages and sub-packages. I think we can run this once a day so speed is not super super critical I would say. > > MDAPI will have to be replaced by local SQLite to increase performance. > I think we could generate most of the content from the repositories' > metadata (last N Fedora + EPEL) but I need to find where the SQL files > lives. A privileged endpoint to dist-get to fetch the package -> > maintainer mapping bypassing pagination would be convenient. > You can look at how mdapi grabs these sqllite files ( https://pagure.io/mdapi/blob/master/f/mdapi-get_repo_md). For the maintainer mapping you should be able to find that here --> https://src.fedoraproject.org/extras/ > We can use Yacy's JSON API to build a sexy fedora-branded search page > but I think it's a late-stage optimization. > +1, would be interesting to see with msuchy if that can be easily integrated with the work he was doing. > -- > Timothée > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Hi, > How does the indexing works ? You point Yacy to a domain or list of URLs (https://fnux.fedorapeople.org/pkgs/ in this case), and it takes care of everything. There is also an advanced crawler panel in the UI allowing you to filter content (e.g. HTML classes) from pages, which would be useful if we do not want to index everything (e.g. dependencies). I am not familiar with the maths used by Yacy for indexing. > And what would it take to add more info for each package ? I wrote a quick script (https://paste.gnugen.ch/raw/4JAC) fetching package metadata from PDC+mdapi for testing, but it is ways too slow to scale to the whole package set. MDAPI will have to be replaced by local SQLite to increase performance. I think we could generate most of the content from the repositories' metadata (last N Fedora + EPEL) but I need to find where the SQL files lives. A privileged endpoint to dist-get to fetch the package -> maintainer mapping bypassing pagination would be convenient. We can use Yacy's JSON API to build a sexy fedora-branded search page but I think it's a late-stage optimization. -- Timothée signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On 4/1/20 4:13 PM, Timothée Floure wrote: > Hi, > > Jumping in since I saw this at the top of the web list archive. This > service is very convenient and I think it would be fairly painful for > the community to see it disappear. Since we do not have the capacity to > develop + maintain new software, I wonder if the following 'low-tech' > approach could work: > > * Generate a static page for each package. > * Crawl/Index it with existing search solution such as Yacy [1] > > We could even extend this search thing to more Fedora websites if it > performs well. I think it might be worth a proof-of-concept, which I can > try to build if you're willing to allocate me some server/VM space for > testing :-) > > [1] https://yacy.net/ I like this idea! I used the packages web app heavily when I was learning to package for Fedora. If the search result redirects to a static page and it is possible to limit what data Yacy crawls, then it would be possible to recreate most of the old packages functionality using a JavaScript framework like Vue. I would like to help if there is a need for any web development. signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, 3 Apr 2020 at 09:18, Timothée Floure wrote: > * Yacy (there might be others to test) running on communityshift: > http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org > * It's indexed against the 20 first PDC packages: > https://fnux.fedorapeople.org/pkgs/ > > * Example looking for 'disk encryption': > http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysearch.html?auth==text=false=disk+encryption+%2Fdate=10=0=ifexist=local=location%2Chosts%2Cauthors%2Cnamespace%2Ctopics%2Cfiletype%2Cprotocol%2Clanguage==0==5=-120=disk+encryption Hi Timothée, the above link is asking for a username password, but I was able to play around using the first url you provided. I think Yacy can be a cool solution to offer a search service for packages, in particular using the JSON api[0] so anyone could use this service and build some cool application if they wanted too. How does the indexing works ? And what would it take to add more info for each package ? [0] - http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysearch.json?query=atomic > > > Looks good so far. I'm curious how relevant/fast the search would be > against 40K packages and ways more details. > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
* Yacy (there might be others to test) running on communityshift: http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org * It's indexed against the 20 first PDC packages: https://fnux.fedorapeople.org/pkgs/ * Example looking for 'disk encryption': http://yacysearchserver-pkgs-playground.apps.os.fedorainfracloud.org/yacysearch.html?auth==text=false=disk+encryption+%2Fdate=10=0=ifexist=local=location%2Chosts%2Cauthors%2Cnamespace%2Ctopics%2Cfiletype%2Cprotocol%2Clanguage==0==5=-120=disk+encryption Looks good so far. I'm curious how relevant/fast the search would be against 40K packages and ways more details. signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Wed, 1 Apr 2020 at 23:20, Timothée Floure wrote: > Hi, > > Jumping in since I saw this at the top of the web list archive. This > service is very convenient and I think it would be fairly painful for > the community to see it disappear. Since we do not have the capacity to > develop + maintain new software, I wonder if the following 'low-tech' > approach could work: > > * Generate a static page for each package. > * Crawl/Index it with existing search solution such as Yacy [1] > I think it is an interesting idea, I don't know about Yacy but I think doing a simple proof-of-concept with maybe a few packages could be interesting. > > We could even extend this search thing to more Fedora websites if it > performs well. I think it might be worth a proof-of-concept, which I can > try to build if you're willing to allocate me some server/VM space for > testing :-) > If you are happy with having something running in containers, you can ask to get access to communishift [0] but mind that this will be offline for a little while in the coming months because of the data centre move. Otherwise I think we could get you instance on AWS probably. Either way if you open an infra ticket [1] with what you need or want we can then look at possible solutions :-). [0] - https://fedoraproject.org/wiki/Infrastructure/Communishift [1] - https://pagure.io/fedora-infrastructure > > [1] https://yacy.net/ > > -- > Timothée > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Hi, Jumping in since I saw this at the top of the web list archive. This service is very convenient and I think it would be fairly painful for the community to see it disappear. Since we do not have the capacity to develop + maintain new software, I wonder if the following 'low-tech' approach could work: * Generate a static page for each package. * Crawl/Index it with existing search solution such as Yacy [1] We could even extend this search thing to more Fedora websites if it performs well. I think it might be worth a proof-of-concept, which I can try to build if you're willing to allocate me some server/VM space for testing :-) [1] https://yacy.net/ -- Timothée signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Mon, 30 Mar 2020 at 14:00, Miroslav Suchý wrote: > Dne 28. 03. 20 v 1:09 Kevin Fenzi napsal(a): > > Hey, any news on this? I guess the problem is as always time. > > > > How far along is it? Could we run a demo/dev version in communishift? > > Yes. Time :( > I have this as huge debt. I will try to prepare something. > > But still I have "just" the page which shows the package detail. @clement > how is the search code doing? I said you will > migrate that part. > Yeah I did not have time to look at this, a while back I started fedora-search [0] to look at using Postgresql full text search capabilities but that seemed quite slow compared to what we have with Xapian. One possible quick way forward would be to extract the code that does the indexing and search from the current packages app and give it as simple search endpoint. While I honestly don't think I will be able to lead that effort, if anyone is interested in working on this I ll be more than happy to help with getting started. [0] - https://github.com/fedora-infra/fedora-search > > -- > Miroslav Suchy, RHCA > Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Dne 28. 03. 20 v 1:09 Kevin Fenzi napsal(a): > Hey, any news on this? I guess the problem is as always time. > > How far along is it? Could we run a demo/dev version in communishift? Yes. Time :( I have this as huge debt. I will try to prepare something. But still I have "just" the page which shows the package detail. @clement how is the search code doing? I said you will migrate that part. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, Nov 22, 2019 at 10:15:43AM +0100, Miroslav Suchý wrote: > Dne 21. 11. 19 v 23:54 Kevin Fenzi napsal(a): > > I hope we can run it in openshift? > > Yes. No problem with that. Hey, any news on this? I guess the problem is as always time. How far along is it? Could we run a demo/dev version in communishift? kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Dne 21. 11. 19 v 23:54 Kevin Fenzi napsal(a): > I hope we can run it in openshift? Yes. No problem with that. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Wed, Nov 20, 2019 at 09:15:40AM +0100, Miroslav Suchý wrote: > Dne 25. 10. 19 v 20:44 Randy Barlow napsal(a): > > > There appears to be work starting on a brand new implementation: > > > https://github.com/xsuchy/fedora-packages-ng > > > > > > This version looks like it'll be Python 3 compatible, though it is > > > quite new. > > We can keep it in mind, thanks for sharing! > > Yes. Give me few additional week. I should finish it before end of December. > It should be drop-in replacement then. Thats excellent news! I hope we can run it in openshift? kevin signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
Dne 25. 10. 19 v 20:44 Randy Barlow napsal(a): There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng This version looks like it'll be Python 3 compatible, though it is quite new. We can keep it in mind, thanks for sharing! Yes. Give me few additional week. I should finish it before end of December. It should be drop-in replacement then. -- Miroslav Suchy, RHCA Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, Oct 25, 2019, 21:42 Randy Barlow wrote: > On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote: > > It's not a bad feature to have in fedpkg, but it fundamentally does > > not help *other people* discover what we have in the distribution. > > Yeah I've discussed this a bit with some people, and I agree. Fedora > *users* might use the packages app to find out the same info that > packagers want to find out. > > However, I think that even though users and packagers are coming to > this app for the same purpose, only one of those purposes maps to the > CPE team's mission statement: the packager's. If you are a packager, > you *need* to know what versions are where at a glance, especially when > dealing with something high priority like a CVE. > > That's not to say that the end-user story isn't a valuable use case, > but our team is overburdened and we need to drop most of what we do > right now, and we have to be specific about what our purpose is. This > means dropping some valuable use cases. > https://pkgs.org/ might be a good replacement for that. Does anybody have used or is using this website ? Any feedback on it ? > Of course, this is also my own opinion, and I welcome disagreement. > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, 2019-10-25 at 15:50 -0400, Neal Gompa wrote: > a lot of Fedora-specific information isn't > present. Though true for the entire packages app, I think this site does do the one use case I described at a quick glance. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote: > It's not a bad feature to have in fedpkg, but it fundamentally does > not help *other people* discover what we have in the distribution. Yeah I've discussed this a bit with some people, and I agree. Fedora *users* might use the packages app to find out the same info that packagers want to find out. However, I think that even though users and packagers are coming to this app for the same purpose, only one of those purposes maps to the CPE team's mission statement: the packager's. If you are a packager, you *need* to know what versions are where at a glance, especially when dealing with something high priority like a CVE. That's not to say that the end-user story isn't a valuable use case, but our team is overburdened and we need to drop most of what we do right now, and we have to be specific about what our purpose is. This means dropping some valuable use cases. Of course, this is also my own opinion, and I welcome disagreement. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, Oct 25, 2019 at 3:48 PM Clement Verna wrote: > > > > On Fri, Oct 25, 2019, 21:42 Randy Barlow wrote: >> >> On Fri, 2019-10-25 at 14:53 -0400, Neal Gompa wrote: >> > It's not a bad feature to have in fedpkg, but it fundamentally does >> > not help *other people* discover what we have in the distribution. >> >> Yeah I've discussed this a bit with some people, and I agree. Fedora >> *users* might use the packages app to find out the same info that >> packagers want to find out. >> >> However, I think that even though users and packagers are coming to >> this app for the same purpose, only one of those purposes maps to the >> CPE team's mission statement: the packager's. If you are a packager, >> you *need* to know what versions are where at a glance, especially when >> dealing with something high priority like a CVE. >> >> That's not to say that the end-user story isn't a valuable use case, >> but our team is overburdened and we need to drop most of what we do >> right now, and we have to be specific about what our purpose is. This >> means dropping some valuable use cases. > > > https://pkgs.org/ might be a good replacement for that. Does anybody have > used or is using this website ? Any feedback on it ? > Some of the searching is a little awkward. It does let you see stuff across distributions, but a lot of Fedora-specific information isn't present. Unfortunately, improving pkgs.org is impossible as the author is hard to get ahold of and the software is not FOSS. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, 2019-10-25 at 21:00 +0200, Mikolaj Izdebski wrote: > I am planning to deploy Package Version Matrix in communishift [1]. > Example how it can look like: [2] > > [1] https://pagure.io/fedora-infrastructure/issue/8314 > [2] https://koji.kjnet.xyz/kojifiles/versions/ Oh that could be a good replacement. Does it support searching, or displaying a particular package rather than the full set (since there are a lot of packages in all of Fedora)? If not, it's probably not hard to add. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, 2019-10-25 at 21:47 +0200, Clement Verna wrote: > https://pkgs.org/ might be a good replacement for that. Does anybody > have used or is using this website ? Any feedback on it ? I haven't seen this before, but if it does a good job staying up to date then it seems like a good replacement to me, and someone else already did it and even hosts it. Nice. signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, Oct 25, 2019 at 8:43 PM Randy Barlow wrote: > OK. Given our extreme time constraints, I think it is likely that we > will have to retire the Packages app. > > However, there is one feature in it that I personally believe does map > to the CPE team's mission statement: the table of which versions of a > package are in which versions of Fedora/EPEL. I am planning to deploy Package Version Matrix in communishift [1]. Example how it can look like: [2] [1] https://pagure.io/fedora-infrastructure/issue/8314 [2] https://koji.kjnet.xyz/kojifiles/versions/ -- Mikolaj Izdebski ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Fri, Oct 25, 2019 at 2:43 PM Randy Barlow wrote: > > On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote: > > The packages app (https://apps.fedoraproject.org/packages/) was > > originally running on RHEL6, I tried to move it to RHEL 7 but they > > were some dependencies missing there so we decided to move it to > > Fedora. I don't remember which dependencies were missing tho. One of > > the pain point is that the frontend is rendered using moksha/tosca > > widgets (http://toscawidgets.org/) and this is pretty much a dead > > upstream project. Removing these dependencies is not going to be > > trivial. > > OK. Given our extreme time constraints, I think it is likely that we > will have to retire the Packages app. > > However, there is one feature in it that I personally believe does map > to the CPE team's mission statement: the table of which versions of a > package are in which versions of Fedora/EPEL. > > I think we should do *something* to continue to provide that particular > feature to packagers. I have a proposal: > > What if we make a fedpkg subcommand that prints that table? I think it > could get all the needed data by querying Koji. > > I suggest this instead of a webapp or service, because webapps and > services increase the burden on the CPE team, and also because creating > an entire application just to print a table is a lot of boilerplate. > > Adding it to fedpkg feels clean to me, because it seems like a sensible > place for such a feature to exist, and because it *should* be simple > and easy. Simple is good! > > I may be able to find the time to make this happen before April too. > > Thoughts? It's not a bad feature to have in fedpkg, but it fundamentally does not help *other people* discover what we have in the distribution. If anything, the biggest problem with CLI tools over web apps is that there's no intuitive way to discover anything. In my view, it does not replace the purpose of the packages web app. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Thu, 2019-10-24 at 20:12 +0200, Clement Verna wrote: > The packages app (https://apps.fedoraproject.org/packages/) was > originally running on RHEL6, I tried to move it to RHEL 7 but they > were some dependencies missing there so we decided to move it to > Fedora. I don't remember which dependencies were missing tho. One of > the pain point is that the frontend is rendered using moksha/tosca > widgets (http://toscawidgets.org/) and this is pretty much a dead > upstream project. Removing these dependencies is not going to be > trivial. OK. Given our extreme time constraints, I think it is likely that we will have to retire the Packages app. However, there is one feature in it that I personally believe does map to the CPE team's mission statement: the table of which versions of a package are in which versions of Fedora/EPEL. I think we should do *something* to continue to provide that particular feature to packagers. I have a proposal: What if we make a fedpkg subcommand that prints that table? I think it could get all the needed data by querying Koji. I suggest this instead of a webapp or service, because webapps and services increase the burden on the CPE team, and also because creating an entire application just to print a table is a lot of boilerplate. Adding it to fedpkg feels clean to me, because it seems like a sensible place for such a feature to exist, and because it *should* be simple and easy. Simple is good! I may be able to find the time to make this happen before April too. Thoughts? signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Thu, Oct 24, 2019 at 2:13 PM Clement Verna wrote: > > > > On Thu, 24 Oct 2019 at 18:07, Randy Barlow > wrote: >> >> Greetings! >> >> The packages app is running on Fedora 30, and its dependencies are not >> available in Fedora 31+ as I understand it. >> >> This means it has about 7 months before we need to do something about >> it, or shut it off. >> >> Do we know if it can run on RHEL 7? > > > The packages app (https://apps.fedoraproject.org/packages/) was originally > running on RHEL6, I tried to move it to RHEL 7 but they were some > dependencies missing there so we decided to move it to Fedora. I don't > remember which dependencies were missing tho. One of the pain point is that > the frontend is rendered using moksha/tosca widgets > (http://toscawidgets.org/) and this is pretty much a dead upstream project. > Removing these dependencies is not going to be trivial. > There appears to be work starting on a brand new implementation: https://github.com/xsuchy/fedora-packages-ng This version looks like it'll be Python 3 compatible, though it is quite new. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: The packages app has a short runway
On Thu, 24 Oct 2019 at 18:07, Randy Barlow wrote: > Greetings! > > The packages app is running on Fedora 30, and its dependencies are not > available in Fedora 31+ as I understand it. > > This means it has about 7 months before we need to do something about > it, or shut it off. > > Do we know if it can run on RHEL 7? > The packages app (https://apps.fedoraproject.org/packages/) was originally running on RHEL6, I tried to move it to RHEL 7 but they were some dependencies missing there so we decided to move it to Fedora. I don't remember which dependencies were missing tho. One of the pain point is that the frontend is rendered using moksha/tosca widgets ( http://toscawidgets.org/) and this is pretty much a dead upstream project. Removing these dependencies is not going to be trivial. > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
The packages app has a short runway
Greetings! The packages app is running on Fedora 30, and its dependencies are not available in Fedora 31+ as I understand it. This means it has about 7 months before we need to do something about it, or shut it off. Do we know if it can run on RHEL 7? signature.asc Description: This is a digitally signed message part ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
Adding that button is quite trivial, a new button after https://pagure.io/pagure/blob/master/f/pagure/themes/srcfpo/templates/repo_info.html#_338 and is done. On September 13, 2019 5:50:43 PM GMT+02:00, Adam Williamson wrote: >On Fri, 2019-09-13 at 13:40 +0100, Ankur Sinha wrote: >> On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: >> > Yeah the packages app is really useful and used by many, this is >the main >> > reason it was not included in the application we are currently >working on >> > giving away / retiring. But to be honest I think the priority of >the packages >> > app is quite low. Following are some of the work we have in our >Backlog : >> > • Packager UX improvement. >> > • FAS replacement. >> > • PDC replacement. >> > • OSBS support for aarch64. >> > • End to End testing and monitoring for the flatpak build >pipeline. >> > • Package review process improvement. >> > • Fedora Infra technical debt. >> >> Is there somewhere community members can read more on these tasks of >the >> CPE please? >> >> For the packages app---if it's in maintenance mode, I guess that's OK >> for the time being until something breaks. >> >> There are two aspects of the packages app that aren't available on >> src.fp.o that make it important for me: >> >> - bugz.fp.o/packagename -> but I expect this can be aliased to a >direct >> bugzilla query type URL? "Open bugs" on the packages app heads to >> bugzilla already: >> >https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED > >The feature this doesn't get you is the handy 'open a new bug for this >package' button. Which again can be replicated as a direct Bugzilla >link, but...you need at least a thing to serve a page showing those two >links :) > >> There are DDG bangs for bugzilla by the way but they don't search >by >> component (I'll suggest a new one soon): !rbugs, !rhbz >> >> - "Install this package" -> this is critical. I was wondering if >there >> was a way to allow users to "click to install", > >There is actually supposed to be a URI format that PackageKit-based >package managers should handle, IIRC, but that was a 2014-vintage thing >or something so no idea if it still works. Julen Landa Alustiza ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Fri, Sep 13, 2019 at 11:51 AM Adam Williamson wrote: > > On Fri, 2019-09-13 at 13:40 +0100, Ankur Sinha wrote: > > On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: > > > Yeah the packages app is really useful and used by many, this is the main > > > reason it was not included in the application we are currently working on > > > giving away / retiring. But to be honest I think the priority of the > > > packages > > > app is quite low. Following are some of the work we have in our Backlog : > > > • Packager UX improvement. > > > • FAS replacement. > > > • PDC replacement. > > > • OSBS support for aarch64. > > > • End to End testing and monitoring for the flatpak build pipeline. > > > • Package review process improvement. > > > • Fedora Infra technical debt. > > > > Is there somewhere community members can read more on these tasks of the > > CPE please? > > > > For the packages app---if it's in maintenance mode, I guess that's OK > > for the time being until something breaks. > > > > There are two aspects of the packages app that aren't available on > > src.fp.o that make it important for me: > > > > - bugz.fp.o/packagename -> but I expect this can be aliased to a direct > > bugzilla query type URL? "Open bugs" on the packages app heads to > > bugzilla already: > > > > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED > > The feature this doesn't get you is the handy 'open a new bug for this > package' button. Which again can be replicated as a direct Bugzilla > link, but...you need at least a thing to serve a page showing those two > links :) > I wonder if we can find some interest with other folks in other RPM distros with the packages app... There isn't much about it that is Fedora-specific. It doesn't even depend on Koji, which means people who use other tooling could use it. So building up a group interested could help with porting it to Python 3 and making it more configurable for usage by other distros (if any such work is needed). > > There are DDG bangs for bugzilla by the way but they don't search by > > component (I'll suggest a new one soon): !rbugs, !rhbz > > > > - "Install this package" -> this is critical. I was wondering if there > > was a way to allow users to "click to install", > > There is actually supposed to be a URI format that PackageKit-based > package managers should handle, IIRC, but that was a 2014-vintage thing > or something so no idea if it still works. It was never implemented as far as I know. That said, I had been recently talking to some folks at openSUSE about developing a new protocol to replace 1-Click-Install (ymp) and some of the other custom things being used. If this is something people want, it's something I can prioritize advancing. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Fri, 2019-09-13 at 13:40 +0100, Ankur Sinha wrote: > On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: > > Yeah the packages app is really useful and used by many, this is the main > > reason it was not included in the application we are currently working on > > giving away / retiring. But to be honest I think the priority of the > > packages > > app is quite low. Following are some of the work we have in our Backlog : > > • Packager UX improvement. > > • FAS replacement. > > • PDC replacement. > > • OSBS support for aarch64. > > • End to End testing and monitoring for the flatpak build pipeline. > > • Package review process improvement. > > • Fedora Infra technical debt. > > Is there somewhere community members can read more on these tasks of the > CPE please? > > For the packages app---if it's in maintenance mode, I guess that's OK > for the time being until something breaks. > > There are two aspects of the packages app that aren't available on > src.fp.o that make it important for me: > > - bugz.fp.o/packagename -> but I expect this can be aliased to a direct > bugzilla query type URL? "Open bugs" on the packages app heads to > bugzilla already: > > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED The feature this doesn't get you is the handy 'open a new bug for this package' button. Which again can be replicated as a direct Bugzilla link, but...you need at least a thing to serve a page showing those two links :) > There are DDG bangs for bugzilla by the way but they don't search by > component (I'll suggest a new one soon): !rbugs, !rhbz > > - "Install this package" -> this is critical. I was wondering if there > was a way to allow users to "click to install", There is actually supposed to be a URI format that PackageKit-based package managers should handle, IIRC, but that was a 2014-vintage thing or something so no idea if it still works. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Fri, 13 Sep 2019 at 14:51, Ankur Sinha wrote: > On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: > > Yeah the packages app is really useful and used by many, this is the main > > reason it was not included in the application we are currently working on > > giving away / retiring. But to be honest I think the priority of the > packages > > app is quite low. Following are some of the work we have in our Backlog : > > > • Packager UX improvement. https://hackmd.io/DIz7xvfDSpyRu9y6BNG6aw > > • FAS replacement. Specification is work in progress > > • PDC replacement. https://hackmd.io/Ef4QgBwMSp-6eFQPChuWag > > • OSBS support for aarch64. No specification yet > > • End to End testing and monitoring for the flatpak build pipeline. > Specification is work in progress > > • Package review process improvement. h > ttps://hackmd.io/TGbwd2yVTlmR_PKicI3CMA > > • Fedora Infra technical debt. > https://pagure.io/fedora-infrastructure/issues :-D > > > Is there somewhere community members can read more on these tasks of the > CPE please? > Sure see links above, not all of these have a spec yet. > > For the packages app---if it's in maintenance mode, I guess that's OK > for the time being until something breaks. > > There are two aspects of the packages app that aren't available on > src.fp.o that make it important for me: > Not available now does not mean that it cannot be made available :-). We have so many code base it is difficult for us to maintain everything, I would rather identify the 2-3 features that the src.fp.o misses to replace the packages app and fill some RFE to the pagure-dist-git project ( https://pagure.io/pagure-dist-git) than spend couple months rewriting the packages app which will fall into maintenance mode after the rewrite and then we will have the same problem in 2 or 3 years. > > - bugz.fp.o/packagename -> but I expect this can be aliased to a direct > bugzilla query type URL? "Open bugs" on the packages app heads to > bugzilla already: > > https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED > > There are DDG bangs for bugzilla by the way but they don't search by > component (I'll suggest a new one soon): !rbugs, !rhbz > > - "Install this package" -> this is critical. I was wondering if there > was a way to allow users to "click to install", but at least having > the `dnf` command there is very useful to most users. > > I'm not flask etc savvy enough to know how easy/hard it is to add these > bits to src.fp.o, but given that src.fp.o is basically a pagure > instance aimed at the development side of things, I expect it isn't the > easiest thing to do? > Pagure supports third party plugins, which could be used to add specific functionality to src.fp.o that would not be needed for pagure.io. We are already doing that for the integration with release-monitoring which is currently being deployed. > > On the other hand, maybe stuff that src.fp.o already provides can be > removed from the packages app to reduce the maintenance burden > ---things like "Changelog" "Sources"? > > I totally understand how busy the CPE team is and unfortunately I'm not > in a position to help much with the infrastructure side of things either. > Yes I know, we also wish we could help but trying to fix 10 things at the same time is not working well. So we are taking the approach of focusing on specific work until complete (currently rawhide gating), unfortunately this means low priority things will suffer from that. I honestly believe this is better, I prefer to tell you that the packages app will very likely be retired in the coming year rather than letting you hope that we will spend a lot of time on it and develop new features. But again this is my vision of the world :-). Just for fun this is the list of the code bases the CPE team is maintains / look after. 1. https://github.com/release-monitoring/anitya 2. https://github.com/fedora-infra/the-new-hotness 3. https://pagure.io/pagure/ 4. https://pagure.io/mdapi/ 5. https://github.com/fedora-infra/fedmsg_meta_fedora_infrastructure/ 6. https://pagure.io/fedora-gather-easyfix 7. https://pagure.io/is-it-in-rhel 8. https://pagure.io/fedora-ci/simple-koji-ci 9. https://github.com/fedora-infra/fedora-messaging 10. https://github.com/fedora-infra/fedmsg-migration-tools 11. https://github.com/fedora-infra/bodhi 12. https://github.com/fedora-infra/fmn 13. https://github.com/fedora-infra/fedora-packages 14. https://github.com/repoSpanner/repoSpanner 15. https://github.com/fedora-infra/fedimg 16. https://pagure.io/sigul 17. https:
Re: State/future of the packages app
On Fri, Sep 13, 2019 09:23:44 +0200, Clement Verna wrote: > Yeah the packages app is really useful and used by many, this is the main > reason it was not included in the application we are currently working on > giving away / retiring. But to be honest I think the priority of the packages > app is quite low. Following are some of the work we have in our Backlog : > • Packager UX improvement. > • FAS replacement. > • PDC replacement. > • OSBS support for aarch64. > • End to End testing and monitoring for the flatpak build pipeline. > • Package review process improvement. > • Fedora Infra technical debt. Is there somewhere community members can read more on these tasks of the CPE please? For the packages app---if it's in maintenance mode, I guess that's OK for the time being until something breaks. There are two aspects of the packages app that aren't available on src.fp.o that make it important for me: - bugz.fp.o/packagename -> but I expect this can be aliased to a direct bugzilla query type URL? "Open bugs" on the packages app heads to bugzilla already: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced=Fedora=Fedora+EPEL=python-rosinstall_generator_status=NEW_status=ASSIGNED_status=REOPENED There are DDG bangs for bugzilla by the way but they don't search by component (I'll suggest a new one soon): !rbugs, !rhbz - "Install this package" -> this is critical. I was wondering if there was a way to allow users to "click to install", but at least having the `dnf` command there is very useful to most users. I'm not flask etc savvy enough to know how easy/hard it is to add these bits to src.fp.o, but given that src.fp.o is basically a pagure instance aimed at the development side of things, I expect it isn't the easiest thing to do? On the other hand, maybe stuff that src.fp.o already provides can be removed from the packages app to reduce the maintenance burden ---things like "Changelog" "Sources"? I totally understand how busy the CPE team is and unfortunately I'm not in a position to help much with the infrastructure side of things either. -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
Yeah the packages app is really useful and used by many, this is the main reason it was not included in the application we are currently working on giving away / retiring. But to be honest I think the priority of the packages app is quite low. Following are some of the work we have in our Backlog : - Packager UX improvement. - FAS replacement. - PDC replacement. - OSBS support for aarch64. - End to End testing and monitoring for the flatpak build pipeline. - Package review process improvement. - Fedora Infra technical debt. On Fri, 13 Sep 2019 at 00:26, Kevin Fenzi wrote: > On 9/12/19 3:00 PM, Frantisek Zatloukal wrote: > > On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi wrote: > > > >> I also used 'pkgwat releases packagename' a lot. (pkgwat was the > >> packages command line app, but it's python2 only, so it went away I > >> fear. > > > > > > Except it did not :) , it's also using Python 3. > > > > https://src.fedoraproject.org/rpms/pkgwat/blob/master/f/pkgwat.spec > > > Cool. I must be thinking of one of the other 11biillion packages that > was python2 only. :) > > kevin > > > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi wrote: > I also used 'pkgwat releases packagename' a lot. (pkgwat was the > packages command line app, but it's python2 only, so it went away I > fear. Except it did not :) , it's also using Python 3. https://src.fedoraproject.org/rpms/pkgwat/blob/master/f/pkgwat.spec ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On 9/12/19 4:16 PM, Kevin Fenzi wrote:
> On 9/12/19 1:12 PM, Adam Williamson wrote:
>> On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote:
>>> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna
>>> wrote:
>>>>
>>>>
>>>> On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote:
>>>>> Hello,
>>>>>
>>>>> I was looking for information on the future of the packages
>>>>> application[1]. I didn't see it mentioned in the commblog post[2].
>>>>
>>>> Currently the application is in a kind of maintenance mode (in reality I
>>>> don't have much time to look at tickets). This application is really
>>>> valuable and used a lot, but the big problem is the technology stack it is
>>>> built on TurboGears2 and making an heavy use of Moksha
>>>> (https://moksha.readthedocs.io/en/latest/), while TG2 is still active
>>>> upstream, this is not the case with Moksha and some of the TG2
>>>> dependencies the application has. The effort to move away from these 2
>>>> framework is quite high and I don't think we currently have the cycles for
>>>> it.
>>>>
>>>> My personal opinion is that we should really try to consolidate on
>>>> src.fp.o and instead of investing time in porting packages to more recent
>>>> technologies we should put that effort in adding the missing features to
>>>> src.fp.o.
>>>>
>>>
>>> If we lose the packages app, we'll lose the only way to search for
>>> binary packages. src.fp.o only shows source package names, and most
>>> people aren't going to know what those are.
>>
>> FWIW, a feature of the packages app I use *all the time* is
>> bugz.fedoraproject.org/ . I can do everything I use that
>> for in other ways, sure, but it's a fantastically helpful shortcut for
>> finding and reporting bugs in .
>>
> mee too. ;(
>
> I also used 'pkgwat releases packagename' a lot. (pkgwat was the
> packages command line app, but it's python2 only, so it went away I
> fear. That was a nice easy way to see what release of a thing was in
> each of the supported branches...
>
Wow. I never even knew about `pkgwat`. I have an alias in my shell that
will pop open the packages app for any rpm name:
```
fpkgpage ()
{
xdg-open https://apps.fedoraproject.org/packages/${1}
}
```
So I use `fpkgpage dnf` or whatever anytime I need to get to a good launch point
to find all the information about a package. I really like the packages app and
will
be really sad to see it go. I use it all the time.
I'm just another one of those freeloaders that can't commit to maintaining it
though.
Dusty
___
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On 9/12/19 1:12 PM, Adam Williamson wrote: > On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote: >> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna >> wrote: >>> >>> >>> On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: >>>> Hello, >>>> >>>> I was looking for information on the future of the packages >>>> application[1]. I didn't see it mentioned in the commblog post[2]. >>> >>> Currently the application is in a kind of maintenance mode (in reality I >>> don't have much time to look at tickets). This application is really >>> valuable and used a lot, but the big problem is the technology stack it is >>> built on TurboGears2 and making an heavy use of Moksha >>> (https://moksha.readthedocs.io/en/latest/), while TG2 is still active >>> upstream, this is not the case with Moksha and some of the TG2 dependencies >>> the application has. The effort to move away from these 2 framework is >>> quite high and I don't think we currently have the cycles for it. >>> >>> My personal opinion is that we should really try to consolidate on src.fp.o >>> and instead of investing time in porting packages to more recent >>> technologies we should put that effort in adding the missing features to >>> src.fp.o. >>> >> >> If we lose the packages app, we'll lose the only way to search for >> binary packages. src.fp.o only shows source package names, and most >> people aren't going to know what those are. > > FWIW, a feature of the packages app I use *all the time* is > bugz.fedoraproject.org/ . I can do everything I use that > for in other ways, sure, but it's a fantastically helpful shortcut for > finding and reporting bugs in . > mee too. ;( I also used 'pkgwat releases packagename' a lot. (pkgwat was the packages command line app, but it's python2 only, so it went away I fear. That was a nice easy way to see what release of a thing was in each of the supported branches... kevin signature.asc Description: OpenPGP digital signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote: > On Thu, Sep 12, 2019 at 2:28 AM Clement Verna > wrote: > > > > > > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: > > > Hello, > > > > > > I was looking for information on the future of the packages > > > application[1]. I didn't see it mentioned in the commblog post[2]. > > > > Currently the application is in a kind of maintenance mode (in reality I > > don't have much time to look at tickets). This application is really > > valuable and used a lot, but the big problem is the technology stack it is > > built on TurboGears2 and making an heavy use of Moksha > > (https://moksha.readthedocs.io/en/latest/), while TG2 is still active > > upstream, this is not the case with Moksha and some of the TG2 dependencies > > the application has. The effort to move away from these 2 framework is > > quite high and I don't think we currently have the cycles for it. > > > > My personal opinion is that we should really try to consolidate on src.fp.o > > and instead of investing time in porting packages to more recent > > technologies we should put that effort in adding the missing features to > > src.fp.o. > > > > If we lose the packages app, we'll lose the only way to search for > binary packages. src.fp.o only shows source package names, and most > people aren't going to know what those are. FWIW, a feature of the packages app I use *all the time* is bugz.fedoraproject.org/ . I can do everything I use that for in other ways, sure, but it's a fantastically helpful shortcut for finding and reporting bugs in . -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, Sep 12, 2019 at 03:14:04PM +0200, Clement Verna wrote: >On Thu, 12 Sep 2019 at 14:56, Neal Gompa <[1]ngomp...@gmail.com> wrote: > > >> >> Is it OK for us to link to the packages application in > documentation, or > >> >> should we just link to src.fp.o already (in the NeuroFedora > >> >> documentation[3]) for example? > >> >> > >> >> The one thing that makes us prefer the packages app is that it has > the > >> >> install command listed there while src.fp.o does not. That makes > the > >> >> packages app somewhat more appropriate for end-users than > >> >> src.fp.o---src.fp.o has links to all the other build pipelines > >> > > >> > > >> > That's sounds like something that could be easily solved. For > example having a simple README.md for each package with a Description, > How to install and How to report Bugs. > >> > > >> > >> It is strategically infeasible to use the README.md file in this way > >> for src.fp.o. If we want data showing up there, we need to adjust > >> src.fp.o itself to show that data. > > > > > > I lack the knowledge here, why would that be strategically infeasible > ? due to the volume of packages ? > > > > It's not just the volume of packages, but also because the README.md > file is editable by committers. It can even be deleted by them. You > can't guarantee anything about the file. > >As far as I understand it the current info we display in the description >and summary come from the spec file which happened to be maintained by the >packagers :-). I would trust the packagers to add the file for their >packages if they don't want it, fine but their packages would be less >user friendly. The summary and description are actually pulled via ajax from mdapi using the template override mechanism built in pagure. I'd actually rely on this more than I would rely on a README.md, a single place that would affect all dist-git repo in Fedora (RPMs and others) w/o having to push commits to 20k+ git repos :) Basically, it means modifying this template: https://pagure.io/pagure/blob/master/f/pagure/themes/srcfpo/templates/repo_info.html Pierre ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, 12 Sep 2019 at 14:56, Neal Gompa wrote: > On Thu, Sep 12, 2019 at 3:20 AM Clement Verna > wrote: > > > > > > > > On Thu, 12 Sep 2019 at 08:41, Neal Gompa wrote: > >> > >> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna > wrote: > >> > > >> > > >> > > >> > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha > wrote: > >> >> > >> >> Hello, > >> >> > >> >> I was looking for information on the future of the packages > >> >> application[1]. I didn't see it mentioned in the commblog post[2]. > >> > > >> > > >> > Currently the application is in a kind of maintenance mode (in > reality I don't have much time to look at tickets). This application is > really valuable and used a lot, but the big problem is the technology stack > it is built on TurboGears2 and making an heavy use of Moksha ( > https://moksha.readthedocs.io/en/latest/), while TG2 is still active > upstream, this is not the case with Moksha and some of the TG2 dependencies > the application has. The effort to move away from these 2 framework is > quite high and I don't think we currently have the cycles for it. > >> > > >> > My personal opinion is that we should really try to consolidate on > src.fp.o and instead of investing time in porting packages to more recent > technologies we should put that effort in adding the missing features to > src.fp.o. > >> > > >> > >> If we lose the packages app, we'll lose the only way to search for > >> binary packages. src.fp.o only shows source package names, and most > >> people aren't going to know what those are. > > > > > > Why can't we enhance src.fp.o to be able to search using binary packages > ? All the data the packages app is using the build the search index is > coming from mdapi (https://mdapi.fedoraproject.org/) so I don't see why > we could not build a similar index as part of src.fp.o and at the same time > improve the search experience there. > > > > Because the search in src.fp.o is the Pagure git repo search. It's > searching for git repos. They just happen to be the same names as the > source packages. :) > I am pretty sure the search functionality is querying the database. PostgreSQL supports full text search so we could build a search index making use of the mdapi info. > > I don't think it'd be appropriate to wire in mdapi into the search, > and it would probably lead to very confusing results. > > >> > >> > >> That said, I'm already working on many different applications that CPE > >> is trying to offload as it is. I can't personally take on this one > >> too. > > > > > > Welcome to our world :-) > >> > >> > >> But perhaps this is worthy of some kind of internship or other student > >> program project? > >> > >> >> > >> >> > >> >> Is it OK for us to link to the packages application in > documentation, or > >> >> should we just link to src.fp.o already (in the NeuroFedora > >> >> documentation[3]) for example? > >> >> > >> >> The one thing that makes us prefer the packages app is that it has > the > >> >> install command listed there while src.fp.o does not. That makes the > >> >> packages app somewhat more appropriate for end-users than > >> >> src.fp.o---src.fp.o has links to all the other build pipelines > >> > > >> > > >> > That's sounds like something that could be easily solved. For example > having a simple README.md for each package with a Description, How to > install and How to report Bugs. > >> > > >> > >> It is strategically infeasible to use the README.md file in this way > >> for src.fp.o. If we want data showing up there, we need to adjust > >> src.fp.o itself to show that data. > > > > > > I lack the knowledge here, why would that be strategically infeasible ? > due to the volume of packages ? > > > > It's not just the volume of packages, but also because the README.md > file is editable by committers. It can even be deleted by them. You > can't guarantee anything about the file. > > > As far as I understand it the current info we display in the description and summary come from the spec file which happened to be maintained by the packagers :-). I would trust the packagers to add the file for their packages if they don't want it, fine but their package
Re: State/future of the packages app
On Thu, Sep 12, 2019 at 3:20 AM Clement Verna wrote: > > > > On Thu, 12 Sep 2019 at 08:41, Neal Gompa wrote: >> >> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna >> wrote: >> > >> > >> > >> > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: >> >> >> >> Hello, >> >> >> >> I was looking for information on the future of the packages >> >> application[1]. I didn't see it mentioned in the commblog post[2]. >> > >> > >> > Currently the application is in a kind of maintenance mode (in reality I >> > don't have much time to look at tickets). This application is really >> > valuable and used a lot, but the big problem is the technology stack it is >> > built on TurboGears2 and making an heavy use of Moksha >> > (https://moksha.readthedocs.io/en/latest/), while TG2 is still active >> > upstream, this is not the case with Moksha and some of the TG2 >> > dependencies the application has. The effort to move away from these 2 >> > framework is quite high and I don't think we currently have the cycles for >> > it. >> > >> > My personal opinion is that we should really try to consolidate on >> > src.fp.o and instead of investing time in porting packages to more recent >> > technologies we should put that effort in adding the missing features to >> > src.fp.o. >> > >> >> If we lose the packages app, we'll lose the only way to search for >> binary packages. src.fp.o only shows source package names, and most >> people aren't going to know what those are. > > > Why can't we enhance src.fp.o to be able to search using binary packages ? > All the data the packages app is using the build the search index is coming > from mdapi (https://mdapi.fedoraproject.org/) so I don't see why we could not > build a similar index as part of src.fp.o and at the same time improve the > search experience there. > Because the search in src.fp.o is the Pagure git repo search. It's searching for git repos. They just happen to be the same names as the source packages. :) I don't think it'd be appropriate to wire in mdapi into the search, and it would probably lead to very confusing results. >> >> >> That said, I'm already working on many different applications that CPE >> is trying to offload as it is. I can't personally take on this one >> too. > > > Welcome to our world :-) >> >> >> But perhaps this is worthy of some kind of internship or other student >> program project? >> >> >> >> >> >> >> Is it OK for us to link to the packages application in documentation, or >> >> should we just link to src.fp.o already (in the NeuroFedora >> >> documentation[3]) for example? >> >> >> >> The one thing that makes us prefer the packages app is that it has the >> >> install command listed there while src.fp.o does not. That makes the >> >> packages app somewhat more appropriate for end-users than >> >> src.fp.o---src.fp.o has links to all the other build pipelines >> > >> > >> > That's sounds like something that could be easily solved. For example >> > having a simple README.md for each package with a Description, How to >> > install and How to report Bugs. >> > >> >> It is strategically infeasible to use the README.md file in this way >> for src.fp.o. If we want data showing up there, we need to adjust >> src.fp.o itself to show that data. > > > I lack the knowledge here, why would that be strategically infeasible ? due > to the volume of packages ? > It's not just the volume of packages, but also because the README.md file is editable by committers. It can even be deleted by them. You can't guarantee anything about the file. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, 12 Sep 2019 at 08:41, Neal Gompa wrote: > On Thu, Sep 12, 2019 at 2:28 AM Clement Verna > wrote: > > > > > > > > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha > wrote: > >> > >> Hello, > >> > >> I was looking for information on the future of the packages > >> application[1]. I didn't see it mentioned in the commblog post[2]. > > > > > > Currently the application is in a kind of maintenance mode (in reality I > don't have much time to look at tickets). This application is really > valuable and used a lot, but the big problem is the technology stack it is > built on TurboGears2 and making an heavy use of Moksha ( > https://moksha.readthedocs.io/en/latest/), while TG2 is still active > upstream, this is not the case with Moksha and some of the TG2 dependencies > the application has. The effort to move away from these 2 framework is > quite high and I don't think we currently have the cycles for it. > > > > My personal opinion is that we should really try to consolidate on > src.fp.o and instead of investing time in porting packages to more recent > technologies we should put that effort in adding the missing features to > src.fp.o. > > > > If we lose the packages app, we'll lose the only way to search for > binary packages. src.fp.o only shows source package names, and most > people aren't going to know what those are. > Why can't we enhance src.fp.o to be able to search using binary packages ? All the data the packages app is using the build the search index is coming from mdapi (https://mdapi.fedoraproject.org/) so I don't see why we could not build a similar index as part of src.fp.o and at the same time improve the search experience there. > > That said, I'm already working on many different applications that CPE > is trying to offload as it is. I can't personally take on this one > too. > Welcome to our world :-) > > But perhaps this is worthy of some kind of internship or other student > program project? > > >> > >> > >> Is it OK for us to link to the packages application in documentation, or > >> should we just link to src.fp.o already (in the NeuroFedora > >> documentation[3]) for example? > >> > >> The one thing that makes us prefer the packages app is that it has the > >> install command listed there while src.fp.o does not. That makes the > >> packages app somewhat more appropriate for end-users than > >> src.fp.o---src.fp.o has links to all the other build pipelines > > > > > > That's sounds like something that could be easily solved. For example > having a simple README.md for each package with a Description, How to > install and How to report Bugs. > > > > It is strategically infeasible to use the README.md file in this way > for src.fp.o. If we want data showing up there, we need to adjust > src.fp.o itself to show that data. > I lack the knowledge here, why would that be strategically infeasible ? due to the volume of packages ? > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna wrote: > > > > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: >> >> Hello, >> >> I was looking for information on the future of the packages >> application[1]. I didn't see it mentioned in the commblog post[2]. > > > Currently the application is in a kind of maintenance mode (in reality I > don't have much time to look at tickets). This application is really valuable > and used a lot, but the big problem is the technology stack it is built on > TurboGears2 and making an heavy use of Moksha > (https://moksha.readthedocs.io/en/latest/), while TG2 is still active > upstream, this is not the case with Moksha and some of the TG2 dependencies > the application has. The effort to move away from these 2 framework is quite > high and I don't think we currently have the cycles for it. > > My personal opinion is that we should really try to consolidate on src.fp.o > and instead of investing time in porting packages to more recent technologies > we should put that effort in adding the missing features to src.fp.o. > If we lose the packages app, we'll lose the only way to search for binary packages. src.fp.o only shows source package names, and most people aren't going to know what those are. That said, I'm already working on many different applications that CPE is trying to offload as it is. I can't personally take on this one too. But perhaps this is worthy of some kind of internship or other student program project? >> >> >> Is it OK for us to link to the packages application in documentation, or >> should we just link to src.fp.o already (in the NeuroFedora >> documentation[3]) for example? >> >> The one thing that makes us prefer the packages app is that it has the >> install command listed there while src.fp.o does not. That makes the >> packages app somewhat more appropriate for end-users than >> src.fp.o---src.fp.o has links to all the other build pipelines > > > That's sounds like something that could be easily solved. For example having > a simple README.md for each package with a Description, How to install and > How to report Bugs. > It is strategically infeasible to use the README.md file in this way for src.fp.o. If we want data showing up there, we need to adjust src.fp.o itself to show that data. -- 真実はいつも一つ！/ Always, there's only one truth! ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Re: State/future of the packages app
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha wrote: > Hello, > > I was looking for information on the future of the packages > application[1]. I didn't see it mentioned in the commblog post[2]. > Currently the application is in a kind of maintenance mode (in reality I don't have much time to look at tickets). This application is really valuable and used a lot, but the big problem is the technology stack it is built on TurboGears2 and making an heavy use of Moksha ( https://moksha.readthedocs.io/en/latest/), while TG2 is still active upstream, this is not the case with Moksha and some of the TG2 dependencies the application has. The effort to move away from these 2 framework is quite high and I don't think we currently have the cycles for it. My personal opinion is that we should really try to consolidate on src.fp.o and instead of investing time in porting packages to more recent technologies we should put that effort in adding the missing features to src.fp.o. > > Is it OK for us to link to the packages application in documentation, or > should we just link to src.fp.o already (in the NeuroFedora > documentation[3]) for example? > > The one thing that makes us prefer the packages app is that it has the > install command listed there while src.fp.o does not. That makes the > packages app somewhat more appropriate for end-users than > src.fp.o---src.fp.o has links to all the other build pipelines > That's sounds like something that could be easily solved. For example having a simple README.md for each package with a Description, How to install and How to report Bugs. > otherwise. > > [1] https://apps.fedoraproject.org/packages > [2] > https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ > [3] https://docs.fedoraproject.org/en-US/neurofedora/compneuro-tools/ > > -- > Thanks, > Regards, > Ankur Sinha "FranciscoD" (He / Him / His) | > https://fedoraproject.org/wiki/User:Ankursinha > Time zone: Europe/London > ___ > infrastructure mailing list -- infrastructure@lists.fedoraproject.org > To unsubscribe send an email to > infrastructure-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org > ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
State/future of the packages app
Hello, I was looking for information on the future of the packages application[1]. I didn't see it mentioned in the commblog post[2]. Is it OK for us to link to the packages application in documentation, or should we just link to src.fp.o already (in the NeuroFedora documentation[3]) for example? The one thing that makes us prefer the packages app is that it has the install command listed there while src.fp.o does not. That makes the packages app somewhat more appropriate for end-users than src.fp.o---src.fp.o has links to all the other build pipelines otherwise. [1] https://apps.fedoraproject.org/packages [2] https://communityblog.fedoraproject.org/application-service-categories-and-community-handoff/ [3] https://docs.fedoraproject.org/en-US/neurofedora/compneuro-tools/ -- Thanks, Regards, Ankur Sinha "FranciscoD" (He / Him / His) | https://fedoraproject.org/wiki/User:Ankursinha Time zone: Europe/London signature.asc Description: PGP signature ___ infrastructure mailing list -- infrastructure@lists.fedoraproject.org To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
