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-c... [3] https://docs.fedoraproject.org/en-US/neurofedora/compneuro-tools/
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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-c... [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-leave@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.fedorapro...
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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.
On Thu, 12 Sep 2019 at 08:41, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com
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-leave@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.fedorapro...
On Thu, Sep 12, 2019 at 3:20 AM Clement Verna cverna@fedoraproject.org wrote:
On Thu, 12 Sep 2019 at 08:41, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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!
On Thu, 12 Sep 2019 at 14:56, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Sep 12, 2019 at 3:20 AM Clement Verna cverna@fedoraproject.org wrote:
On Thu, 12 Sep 2019 at 08:41, Neal Gompa ngompa13@gmail.com wrote:
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna cverna@fedoraproject.org
wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com
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-leave@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.fedorapro...
On Thu, Sep 12, 2019 at 03:14:04PM +0200, Clement Verna wrote:
On Thu, 12 Sep 2019 at 14:56, Neal Gompa <[1]ngompa13@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_i...
Pierre
On Thu, 2019-09-12 at 02:32 -0400, Neal Gompa wrote:
On Thu, Sep 12, 2019 at 2:28 AM Clement Verna cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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/<packagename> . 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 <packagename>.
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 cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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/<packagename> . 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 <packagename>.
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
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 cverna@fedoraproject.org wrote:
On Wed, 11 Sep 2019 at 15:06, Ankur Sinha sanjay.ankur@gmail.com 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/<packagename> . 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 <packagename>.
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/$%7B1%7D } ```
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
On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi kevin@scrye.com 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
On 9/12/19 3:00 PM, Frantisek Zatloukal wrote:
On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi kevin@scrye.com 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
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 kevin@scrye.com wrote:
On 9/12/19 3:00 PM, Frantisek Zatloukal wrote:
On Thu, Sep 12, 2019 at 10:17 PM Kevin Fenzi kevin@scrye.com 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-leave@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.fedorapro...
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&product=Fe...
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.
On Fri, 13 Sep 2019 at 14:51, Ankur Sinha sanjay.ankur@gmail.com 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&product=Fe...
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 23. https://pagure.io/basset 24. https://github.com/fedora-infra/python-fedora 25. https://pagure.io/releng/tag2distrepo 26. https://pagure.io/cccolutils 27. https://github.com/fedora-infra/datagrepper 28. https://github.com/fedora-infra/kitchen 29. https://github.com/fedora-infra/datanommer 30. https://github.com/fedora-infra/fedmenu 31. https://github.com/fedora-infra/pkgwat.cli 32. https://github.com/fedora-infra/pkgwat.api 33. https://github.com/fedora-infra/asknot-ng 34. https://github.com/fedora-infra/github2fedmsg 35. https://github.com/fedora-infra/bugzilla2fedmsg 36. https://github.com/fedora-infra/statusfpo 37. https://github.com/fedora-infra/supybot-fedora 38. https://github.com/fedora-infra/apps.fp.o 39. https://pagure.io/pagure-dist-git
As it's stands today we are 5 developers (that is likely going to grow to 7 or 8) for almost 40 code bases. So If you know developer that enjoy working with legacy code base feel free to send them our way :-D
-- 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-leave@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.fedorapro...
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&product=Fe...
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.
On Fri, Sep 13, 2019 at 11:51 AM Adam Williamson adamwill@fedoraproject.org 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&product=Fe...
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!
Adding that button is quite trivial, a new button after https://pagure.io/pagure/blob/master/f/pagure/themes/srcfpo/templates/repo_i... and is done.
On September 13, 2019 5:50:43 PM GMT+02:00, Adam Williamson adamwill@fedoraproject.org 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&product=Fe...
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 jlanda@fedoraproject.org
infrastructure@lists.fedoraproject.org