package popularity ratings

[Seth Vidal]

Hi,
 I got this bug assigned to yum the other day:

https://bugzilla.redhat.com/show_bug.cgi?id=446836

it's not really a yum item, yet, b/c yum can really only USE the data,
not generate it.

However, I don't know where it should go. Is anyone working on this sort
of thing?

-sv

[Michael DeHaan]

seth vidal wrote:
> Hi,
>  I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this sort
> of thing?
>
> -sv

"

Very similar to ubuntu's popularity meter,
but better.
"

Cough, *Debian*, cough.

I'd be interested in this too.   Smolt has opt-in ways to send stats, could we hijack that submission infrastructure to also do software inventory?

If so, the code seems like it would be pretty simple.

We'd probably want that to be /another/ opt in switch since it's slightly different info?

--Michael

[Daniel P. Berrange]

On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
> Hi,
>  I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this sort
> of thing?

Isn't any package popularity rating going to be hugely skewed such that
the 'default install set' packages are basically always rated top, making
rankings of dubious value

Dan.

[Seth Vidal]

On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote:
> On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
> > Hi,
> >  I got this bug assigned to yum the other day:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=446836
> >
> > it's not really a yum item, yet, b/c yum can really only USE the data,
> > not generate it.
> >
> > However, I don't know where it should go. Is anyone working on this sort
> > of thing?
>
> Isn't any package popularity rating going to be hugely skewed such that
> the 'default install set' packages are basically always rated top, making
> rankings of dubious value

that's been my general impression which is why I was curious who wanted
to look at it since my overt bias against them is a bit discouraging :)

-sv

[Daniel P. Berrange]

On Tue, May 27, 2008 at 05:39:51PM -0400, seth vidal wrote:
> On Tue, 2008-05-27 at 22:25 +0100, Daniel P. Berrange wrote:
> > On Tue, May 27, 2008 at 03:53:18PM -0400, seth vidal wrote:
> > > Hi,
> > >  I got this bug assigned to yum the other day:
> > >
> > > https://bugzilla.redhat.com/show_bug.cgi?id=446836
> > >
> > > it's not really a yum item, yet, b/c yum can really only USE the data,
> > > not generate it.
> > >
> > > However, I don't know where it should go. Is anyone working on this sort
> > > of thing?
> >
> > Isn't any package popularity rating going to be hugely skewed such that
> > the 'default install set' packages are basically always rated top, making
> > rankings of dubious value
>
> that's been my general impression which is why I was curious who wanted
> to look at it since my overt bias against them is a bit discouraging :)

I think a more useful metric would be a popularity list based on  which
programs are *run*.  You'd obviously have to exclude things that are
typically batch-run/scripted - eg bash would dominate. Count any binary
run with a .desktop file perhaps, although that'd exclude mutt and emacs.
IIRC  mugshot/gnome live is already able to track this kind of metric

Dan.

[Jef Spaleta]

On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange  wrote:
> Isn't any package popularity rating going to be hugely skewed such that
> the 'default install set' packages are basically always rated top, making
> rankings of dubious value

I personally see zero value in a flat popularity rating.
I would see more value if we could find a way to correlate users such
that I could datamine the application preferences of people who were
already running systems similar to mine.

For example, XFCE users as a breed might prefer certain applications
which are not 'popular' in the general userbase, but were immensely
popular inside the XFCE subculture. Those shared preferences would
never show up in a flat popularity rating..a rating destined to be
dominated by FVWM2 users...so such a flat rating would never really be
what XFCE users would find value in.

But if we had a way to correlate a systems/usages/people with other
systems/usages/people which are mostly similar, then we have something
interesting as a metric...a metric that can support both common and
niche subgroups..based solely on individual usage cases or habits.
That way XCFE users, would end up correlating with other XCFE users
and would have the software 'popularity' ranking biased by that
correlation.

It would end up being dynamic, in that as your usage patterns changed,
how you would correlate with others would change as well without
anyone elses habits changing.

Centralization of 'popularity' is simply not flexible enough to be
interesting in the brave new world of the social network.

-jef"Did i mention that I hate social networking"spaleta

[Stephen John Smoogen]

On Tue, May 27, 2008 at 4:43 PM, Jeff Spaleta  wrote:
> On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange  wrote:
> > Isn't any package popularity rating going to be hugely skewed such that
> > the 'default install set' packages are basically always rated top, making
> > rankings of dubious value
>
> I personally see zero value in a flat popularity rating.
> I would see more value if we could find a way to correlate users such
> that I could datamine the application preferences of people who were
> already running systems similar to mine.
>
> For example, XFCE users as a breed might prefer certain applications
> which are not 'popular' in the general userbase, but were immensely
> popular inside the XFCE subculture. Those shared preferences would
> never show up in a flat popularity rating..a rating destined to be
> dominated by FVWM2 users...so such a flat rating would never really be
> what XFCE users would find value in.

They would be better suited with:

People who installed Thunar also installed ... bsd-games and fortune_mod
> -jef"Did i mention that I hate social networking"spaleta

Stephen "Amazon is our salvation..." Smoogen

[Yaakov Nemoy]

On Wed, May 28, 2008 at 12:43 AM, Jeff Spaleta  wrote:
> On Tue, May 27, 2008 at 1:25 PM, Daniel P. Berrange  wrote:
> > Isn't any package popularity rating going to be hugely skewed such that
> > the 'default install set' packages are basically always rated top, making
> > rankings of dubious value
>
> I personally see zero value in a flat popularity rating.
> I would see more value if we could find a way to correlate users such
> that I could datamine the application preferences of people who were
> already running systems similar to mine.
>
> For example, XFCE users as a breed might prefer certain applications
> which are not 'popular' in the general userbase, but were immensely
> popular inside the XFCE subculture. Those shared preferences would
> never show up in a flat popularity rating..a rating destined to be
> dominated by FVWM2 users...so such a flat rating would never really be
> what XFCE users would find value in.
>
> But if we had a way to correlate a systems/usages/people with other
> systems/usages/people which are mostly similar, then we have something
> interesting as a metric...a metric that can support both common and
> niche subgroups..based solely on individual usage cases or habits.
> That way XCFE users, would end up correlating with other XCFE users
> and would have the software 'popularity' ranking biased by that
> correlation.
>
> It would end up being dynamic, in that as your usage patterns changed,
> how you would correlate with others would change as well without
> anyone elses habits changing.
>
> Centralization of 'popularity' is simply not flexible enough to be
> interesting in the brave new world of the social network.

This is actually an old issue, and it got brought up again last
February when I spoke to the people at OpenSuSE.  But first, a little
history.

When Smolt was started, there were privacy concerns.  The decision was
to restrict the amount of information collected, to ensure that there
would be fewer complaints.  The final decision was to collect no
packaging information.

Then, I came up with a privacy scheme that should eliminate 95% of the
legitimate concerns one may have.  This reopened the decision to
collect arbitrary information.  Nevertheless, Smolt and the project is
concerned primarily with hardware, although we can be linked to easily
with other databases.  Personally, I would like to see packaging
information kept out of our database anyways, just for complexity
issues.

Then, I spoke with some people from OpenSuSE and they mentioned that
they had a similar project, one which collected information about the
initially installed DE.  We may include the capability to collect this
information in a future version but it will probably be disabled by
default on Fedora.  If it does get setup, in the Fedora Land, the
values would be determined by which DE package groups have been
installed.  Even so, the information can be selectively hidden from
smolt, if the user prefers.

Finally, I am interested in combining several programs into the
firstboot screen.  This way, we can make it easy for the user to
decide how participatory he wants to be.  Getting this together is on
the Agenda for the summer.  That said, Smolt itself won't be concerned
with package information and details.

- Yaakov "sick of recurring conversation threads" Nemoy

[Robin Norwood]

On Tue, 27 May 2008 15:53:18 -0400
seth vidal  wrote:
> Hi,
>  I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this
> sort of thing?

I'm looking at something along these lines, but don't have anything to
show yet.  I should have something for public consumption (text, not
code) this week.

-RN

[David Nielsen]

2008/5/27 Robin Norwood :
> On Tue, 27 May 2008 15:53:18 -0400
> seth vidal  wrote:
> > Hi,
> >  I got this bug assigned to yum the other day:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=446836
> >
> > it's not really a yum item, yet, b/c yum can really only USE the data,
> > not generate it.
> >
> > However, I don't know where it should go. Is anyone working on this
> > sort of thing?

Doesn't mugshot collect this kind of data for it's application
recommendations?

[Pierre-Yves Chibon]

seth vidal wrote:
> Hi,
>  I got this bug assigned to yum the other day:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=446836
>
> it's not really a yum item, yet, b/c yum can really only USE the data,
> not generate it.
>
> However, I don't know where it should go. Is anyone working on this sort
> of thing?

I do not think that user would be that much interesting in 
having/knowing the top 1000 software used...
By doing this that would influence them, and oriented them to the most 
used one... better stay in another famous and world well known 
proprietary software that almost every one use...

But I do think that I would like to have this information for the 
package I maintain !
Nowadays as packager the only feed back that told me that my packages 
are used is basically bugzilla, which mean that if I have packaged a 
good software that runs without problem I have no idea whether I have 
worked for myself or if other people are actually using it.

In brief:
* I do not want/need these information for all the packages as a user
* I want these information for my packages as I am a packager.

Hope it makes sense :)

Regards,
Pierre