Any progress in Software Center in Fedora effort?
kevin at scrye.com
Mon Oct 8 22:23:17 UTC 2012
On Mon, 8 Oct 2012 18:16:28 -0400
Matthew Miller <mattdm at fedoraproject.org> wrote:
> On Mon, Oct 08, 2012 at 11:18:33PM +0200, drago01 wrote:
> > > That is a web application.
> > No it isn't.
> > > The software has to be stored somewhere to
> > > be gotten from.. and that requires disk space, front end servers,
> > > and other infrastructure.
> > This is not about a webportal .... just some files on the mirrors in
> > addition to the existing metadata.
> This is why we need a clear plan, because right now everyone is
> talking about a different imagined thing. I *think* you're just
> talking about getting the appdata.xml metadata from desktop files
> into the mirrors:
> (I see also that I missed the "icons" tar.gz that needs to go
> alongside that.)
The last time this came up, some folks wanted to put all the icons and
app desktop file data into a package and ship it and install it by
default. Others found this a bad idea and wanted to generate the data
on the server side and serve it to folks. The folks wishing to push the
package are stalled in legal (because shipping a package with all icons
in it means that each icon is under the license of whatever package it
came from, making the resulting rpm license... very silly). The folks
who wanted to generate the data as far as I know didn't get to far
toward doing so, AFAIK.
So, yes, this would need a clear plan. ;)
> But the whole Freedesktop plan has a whole bunch of other parts. Is
> that what we're talking about implementing in general?
> Is this the best architecture for Fedora? Does it provide the user
> experience we want? If so (or if not, but we want to do something else
> instead), what does the non-abstract version of that diagram look
> like for our implementation? Who will do what parts, where will they
> run, and who will keep those parts running?
If we decide this is the way we want to go, any such work would need to
use the Infrastructure Request for Resources process:
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the devel