On Thu, Sep 12, 2019 at 3:20 AM Clement Verna <cve...@fedoraproject.org> wrote: > > > > On Thu, 12 Sep 2019 at 08:41, Neal Gompa <ngomp...@gmail.com> wrote: >> >> On Thu, Sep 12, 2019 at 2:28 AM Clement Verna <cve...@fedoraproject.org> >> wrote: >> > >> > >> > >> > On Wed, 11 Sep 2019 at 15:06, Ankur Sinha <sanjay.an...@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! _______________________________________________ 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
