On 5 March 2013 20:02, Ryan Lerch <rlerch(a)redhat.com> wrote:
Does this mean that the Application data will be something that
Fedora will
need to host in addition to the data already in the packages?
Depends if Fedora wants to have application icons and translated
descriptions -- See
https://bugzilla.redhat.com/show_bug.cgi?id=488968
for all the grotty detail. I'm not going to solve that one as I burned
out pretty hard a couple of years ago fighting with people. I'm happy
to design the tools to be pluggable and for someone in Fedora to give
me some metadata and a way to update it. If that's a XMLRPC call, a
bit of yum metadata or a separate package I don't care. Sorry if this
sounds harsh, but I got pretty upset with the behaviour of some people
in Fedora back when we were designing AppStream and I don't want a
repeat of that.
Also, the current mockups for the applications page on GNOME wiki
don't have
any ratings or comments for applications.
It's got ratings in the application details page. Where that data
comes from for Fedora is still unknown, but I was hoping to harvest
some data from pkgdb. It doesn't have to be updated in real-time,
ratings will change slowly, and we probably want to game the system a
little at first anyway.
Was this something that was
considered in the design? (although this sounds like it will encounter the
same issue as the application data, needing something external outside the
packages)
Comments are tricky. Comments need people to review them (mark as
inappropriate,etc) and also need to be handled per-locale, i.e.
there's no point in showing a French comment to a Japanese user, which
means per-locale moderation. I'm not sure comments are particularly
useful. Tags on the other hand are...
Have you got any further information on the design thinking behind
the "OS
Updates"? will that just install all the non-applications packages that are
available at the time?
At the moment, the heuristic is "it's an app, new entry, otherwise
stick in os-updates" -- so it includes stuff like -devel, -debuginfo
-libs etc. Not ideal at all, but that's the price we pay for having
everything so granular as packages.
furthermore, if one of my applications needs a
separate package updated as a dependency, will it install the entire "OS
update"? or will it just update the packages are required to update that
application?
Just the required packages, not everything. And it currently updates
the deps without even asking, which is a feature not a bug.
Finally, even though they aren't GUI applications, should
standalone
terminal applications (e.g. mutt, irissi or vim) also be considered an
"Application"?
Nope, applications have desktop files that get shown in the GUI menus,
with a few things blacklisted. Anything other than than leads you down
a slippery slope where stuff like openldap and abrt become
applications, and then you've got no concept of a base-os any more.
It's my personal opinion of course, but I've been thinking about a
good way of delineating and defining applications|base-os for quite
some time. If something like GVim ships a desktop file, then it'll get
included, vim not so. irissi is a power user tool, and those kind of
people are quite comfortable doing "yum install irissi" or "zif
install vim"
Richard.