Hi, not that I'd oppose the idea as a whole, but I'm a bit concerned about this part: a from the user's point of view, even if it is only "a couple megabytes", I'm not that happy if my precious resources are eaten up by things I do not use (while not that important on a desktop with unlimited 100 Mbps internet connection, situation could be quite a different on some mobile device with pretty expensive mobile connection) from the developers point of view, I just wonder what will happen with the icons packaged with the applications - are they going to be moved (i.e. a lot of cross-dependencies created and some extra work as we'd need to update two packages), or are they going to be duplicated (how will we ensure that it wouldn't get out of sync), or what? K. p.s. somehow I cannot understand how do the translations work ... -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol(a)jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."

* Elad Alfassa [11/08/2014 19:28] : The problem isn't so much storage but bandwidth. Some people have capped or slow bandwidth and don't appreciate packages that are regularly rebuilt and pushed as updates. I'ld love some data so that we can better make up our minds. How many .desktop files do we ship? How many of these do we want to advertise via gnome-software? Etc... Emmanuel

Hi, and unlimited some now I'm confused, as you talked about putting it into *-release ...? much "relatively" is the key what is cheap for you doesn't mean cheap for everyone - for sure, storage is much cheaper than x years ago, but many people keep those x years old computers as they still work and I don't see any reasons to force them to upgrade just for _optional_ features (in fact, they often switched to linux because Windows would force them to buy new hardware) ... maybe you change the furniture in your house (and the whole house?) each two years or so, but I keep it until it is broken beyond repair, and the same goes for electronic devices, they serve until they are able to serve ... I just hate those piles of old crap in our backyards, and those poisons in the air/water/soil emitted while manufacturing all the new crap ... 7 MB in a distro that has about 10 GB installed packages by default seems like nothing ... but I just find the attitude wrong - how did we got to those 10 GB when my (and hardly any other _home_ user's) productivity with the software hasn't increased since early nineties when I had about 30 MB for system and 50 MB for data (and in some cases, software that had output/workflows of the same quality as recent applications existed even in 1980's ...)? and it's not only the old hardware - another thing is miniaturization, it may be cheap to buy a new SD card, but if you have just one slot in your Raspberry Pi ... similarly it goes for the bandwith as mentioned by Emmanuel - deltarpm is nice, but it has its own problems ... if the estimated number of Fedora users is about 2.5 million, in theory, if 1% of them would have pay-per-megabyte connection, the price would be 0.005 cents per kilobyte on average[*], and deltarpm would manage to squeeze the update to 10 kilobytes, that's 2.5 M * 1% * 10 KB * 0.005 c = $1250 per one update [*] I'm using the price of my mobile connection which I think is somewhere in the middle between developed and developing countries of course, the number is completely made up, it's just for putting things into context ... it's cheap when you don't have to pay those $1250 weekly from your pocket (and no single person would care about 0.05 cents), right? (... and no one cares how much that additional load costs the owners of download mirrors) now let's go further ... if the typical installation has about 2000 packages, what if there would be something "nice to have" for each of them that would increase the size of the package by those "cheap" seven megabytes? dismissing concerns as "it is just one slice of salami, that's nothing" is IMO very misleading we need to think in the global numbers - take UPS as an example: planning for one car doesn't make difference, planning for tens thousands? - http://www.pressroom.ups.com/Fact+Sheets/Saving+Fuel:+UPS+Saves+Fuel+and+... so yes, provide new features, but think how to minimalise the negative impact and how to allow opt-out for those who do not need/want them (and even if it shouldn't be rather opt-in than default that needs to be opted-out) the a are so it will be duplicated ... rpm still cannot handle multiple ownership of a file? "you" means me as the application maintainer, or someone else who will maintain AppData? "regular package update" means AppData upgrade and not e.g. in my example qmmp? hm, I don't feel any wiser now :-( I (or the upstream developer) can implement my own way of getting translations to the XML files only if I know how it should look like in the XML file? - there doesn't seem to be any DTD available, and the "File specification" doesn't give a damn about different languages handling (except for the note that screenshots should be taken in English) looking at the example: http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch I see exactly _zero_ localised strings what seems interesting is "+@INTLTOOL_XML_RULE@", okay, so let's take a look how does it work, let's go to homepage: http://freedesktop.org/wiki/Software/intltool/ um, no single mention of any such macro, well, in fact, no documentation at all? seriously? do I really have to read sources of that crap to get basic understanding what does it do? K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol(a)jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."

Hi, Dne středa, 13. srpna 2014 10:32:58 CEST, Elad Alfassa napsal(a): in I thought I've read that carefully ... in the first e-mail, you've written: "They can also be distributed in a different package ... but the user experience will suffer" from which I boldly deduced that putting it into *-release is your preferred method then you change to "That's why I suggested ... using a separate package." the fact is that now you're formally correct, you've really mentioned both options but you've put one before the second and treated the second as inferior and in the followup you turn 180 degrees and say you have reasons for the second maybe I was too hasty to deduce that you'd prefer the method where user experience won't suffer, but I just don't like this style of communication where you say you're suggesting something you were arguing against, dude be so, the application package will install a file that is of no use except "when building and composing distributions"[1] on which ocassion the contents will be copied to some database (probably in /usr/share/app-info/xmls [2]), that takes some more 3.3 MB / 769 KB un/packed[3]? either I am missing something, or the design is heavily flawed the cherry on top is (again [1]): What happens if I don't ship this file? The GNOME Software Center currently shows a nag message that the upstream project doesn't ship the additional data. Additionally, we will penalize apps that do not ship the extra metadata by showing them lower in the search results. - cool, so the project is here not to help users, but to boost ego of some developers that have the urge to force others to do additional work to implement the one and only right_way(tm) of providing application description ... or how should I interpret the fact that they are going to make it harder for users to find what they search for? [1] from http://people.freedesktop.org/~hughsient/appdata/ [2] guessing from http://people.freedesktop.org/~hughsient/temp/appstream-data.spec [3] http://people.freedesktop.org/~hughsient/temp/fedora-20.xml.gz http://freedesktop.org/wiki/ why not to call things the names they deserve? good documentation is an essential part of good project however, I do put it into the source tree (be the files *.po or *.ts or whatever) - and there is nothing like that in the example patch[4], that touches more files than just gcm-viewer.appdata.xml.in [4] http://people.freedesktop.org/~hughsient/appdata/example-intltool.patch ok, so it is like xgettext[5] but it handles xml ... [5] btw, https://www.gnu.org/software/gettext/manual/gettext.html /usr/share/appdata/totem.appdata.xml okay, that explains the question - so the locales are not in some kind of *.mo files but directly inside the *.xml file distinguished by the 'xml:lang="code"' attribute it may seem trivial to you, but I've never worked with this before and I just can't get information out of vacuum - xml is only a container that can be used in many ways, and the sole possibility to add Language identification as per section 2.12 of the XML 1.0 recommendation doesn't imply anything about actual implementation (it could have been e.g. multiple files, one per language, as the abovementioned .mo works, or the translations could have been kept separately in message catalogs etc.) I'd tend to disagree - if file(s) installation is involved then the packager should know how do the things work; he may even assist upstream (author) if the request to provide the file comes from downstream (distribution) mail assist well, right I'm just surprised that this is the first place I hear about it ... my primary role is not in development, so I'm not subscribed on devel, as I expect all important changes coming through devel-announce (maybe I just haven't paid enough attention?) anyways, I've put my concerns to the ticket https://fedorahosted.org/fpc/ticket/414#comment:31 so, in 2014, the greenhouse effect and money spent in vain is of less importance than it was in 1995? K. -- Karel Volný QE BaseOs/Daemons Team Red Hat Czech, Brno tel. +420 532294274 (RH: +420 532294111 ext. 8262074) xmpp kavol(a)jabber.cz :: "Never attribute to malice what can :: easily be explained by stupidity."

The point of this thread is not to judge how the new Software app works. If someone has suggestions that would improve it, he/she should go upstream (Gnome). Elad's proposal is about deciding if we want RPMFusion packages to be accessible to Desktop Fedora users or not. It's that simple.

On Thu, 2014-08-14 at 02:07 +1000, Ankur Sinha wrote: I did a trial run today. Interested folks can see the results on the bug here: https://bugzilla.rpmfusion.org/show_bug.cgi?id=2998#c10 The generated metadata and rpm are only about 350K at the moment. -- Thanks, Warm regards, Ankur (FranciscoD) http://fedoraproject.org/wiki/User:Ankursinha Join Fedora! Come talk to us! http://fedoraproject.org/wiki/Fedora_Join_SIG

On Mon, 2014-08-11 at 18:06 +0300, Elad Alfassa wrote: +1. I think it's really frustrating for end users that they can't currently find RPMfusion applications through Software Center (which is the default and only preinstalled application for installing new software). ~nikos