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. > > 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
