On 5 March 2013 20:02, Ryan Lerch <rlerch@xxxxxxxxxx> 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. -- desktop mailing list desktop@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/desktop
