popularity package context on fedora

[Jeff Spaleta]

On Mon, May 3, 2010 at 12:19 PM, yersinia <yersinia.spiros at gmail.com> wrote:
> Sure, I can try. If one software is used  many time from many user, directly
> or indirectly, and it have not such many  problems (e.g bug open on bugzilla
> for example ), well this  could guide to the decision of the goodness of the
> software and the need to delete it or not if the maintainer does not believe
> to support it yet.

Are you speaking as a member of the QA team?  This sounds very
hypothetical..and not very specific. I'm really not sure that popcon
is going to tell us anything about fitness of a package in a way that
bugzilla does not already....especially when popcon its not setup to
provide enough details in its summary reports to distinguish
individual versions of one against another...let alone whether they
are testing versions or what not.  I don't see how this data is useful
at all compared to abrt and bugzilla in doing any sort of QA for
anyone.

Here's a little exercise .  Go into debian's bug tracking system and
compare the rank order popularity of a package in popcon with the rank
ordering of number of bugs filed against that package in debian's
ticketing system for all time.  There is a popular theory that holds
that all software is roughly equally buggy and that roughly speaking
the number of people reporting problems scales with its
popularity...not with its general fitness.

To be useful for package QA we'd really have to tie it into bodhi to
give detailed information about how many people are using a given
testing updates compared to nominal usage to help maintainers feel
confident that its seen enough testing even when there's been no karma
added or subtracted. But such an integrated system would not look
anything like popcon and a there would need to be a sit down
discussion with bodhi developers on how to best integrate that sort of
client side data.


> Conversely, if software is not used - directly or
> indirectly - this could facilitate the decision to remove it, in the event
> that this possibility emerge.

Popcon is designed as an opt-in system. You cannot rely on it giving
it accurate results on actual usage for the full breath of our
repository. Nor the Debian repository for that matter.  We carry a
significant number of niche packages...packages that will not be seen
by popcon-like data collection unless you get a significant proportion
of the userbase running it and catch all possible usage scenarios.

If you are proposing that the project employ a data driven package
expiration policy.. then lets figure out what that policy needs to be
and build data collection to meet its requirements...not build the
data collection then build the policy that fits after the fact.

I do not want to see data collected just because its possible to
collect. I want there to be a specific reason and a firm commitment to
using the data that we can communicate to our users.

-jef