On Thu, Jan 09, 2014 at 10:45:44PM +0100, Michael Schwendt wrote: > On Thu, 9 Jan 2014 22:20:10 +0100, Alec Leamas wrote: > > > Yes, still it's an interesting issue... perhaps one count how many which > > actually are installed, > > "Installed and used actively" would be more interesting. > > Especially with regard to optional plugins, which perhaps are not > loaded/executed at runtime automatically. For example, multimedia users > follow instructions found on the web that lead to installing all codec > packages, whether they need them or not. Watching statistics you might > think "hey, there are WavPack or Musepack users", but maybe they never > use files of that type. it'd be interesting to know how debian QA takes metrics like these: http://qa.debian.org/popcon-graph.php?packages=python-bottle%2C+python-flask&show_installed=on&want_legend=on&from_date=&to_date=&hlght_date=&date_fmt=%25Y&beenhere=1 I haven't looked but pretty sure these are not recorded via some unauthorized callback (being debian and all), perhaps these are just rough download statistics. > > > but many problems also here: users privacy/opt-in, > > easily spoofed, infrastructure. > > And it wouldn't force a packager in any way, maybe serve as some minor > influence only. > > It would not be the first plugin/subpackage that has been discontinued > during the lifetime of a distribution. > > If a package were considered "popular enough", the packager would > not want to upgrade the software to a newer version that removes the > package? There are other more important factors when considering a > version upgrade. > > And probably most important, you cannot get an obsolete package to > reinstall automatically once it would become available again. User > would need to take notice and reinstall manually (unless packager > plays tricks or makes it a new requirement). The package may not come back any time soon, and I actually have no idea if patching it back from the old sources would be feasible (I haven't looked to what extent it is broken.) If it does come back in the future I understand it should be named something else... should that potential future package _also_ obsolete this one? (I don't think so?) > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- ~kad
Attachment:
pgpf_aJx2jokL.pgp
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
