On Thu, 12 Sep 2019 at 14:56, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Thu, Sep 12, 2019 at 3:20 AM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote:
>
>
>
> On Thu, 12 Sep 2019 at 08:41, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>>
>> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna <cverna@xxxxxxxxxxxxxxxxx> wrote:
>> >
>> >
>> >
>> > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha <sanjay.ankur@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
