On Thu, Jan 09, 2014 at 02:38:50PM -0800, Jorge Gallegos wrote: > 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. Hah!, found it right after I sent the email: http://popcon.debian.org > > > > > > 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 -- ~kad
Attachment:
pgpyI1B61H5AG.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