Re: Sub-package dropped upstream

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux