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://github.com/puiterwijk/flask-oidc/ 18. https://github.com/puiterwijk/libgit2-repospanner 19. https://pagure.io/ipsilon 20. https://github.com/fedora-infra/fas 21. https://github.com/fedora-infra/fas-client 22. https://pagure.io/robosignatory
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 packages would be less user friendly. Any how this is just my opinion as I mentioned :-). Regarding the future of the packages app, I think that in the current state it will be just shut down when we can run it anymore (this is still a Python 2 application). > > > -- > 真実はいつも一つ！/ 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, 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
