More statistics

[Dimitris Glezos]

I saw this today:

  http://people.mozilla.com/~jscott/devcp/latest/

It's a stats dashboard, showing a high level picture of the project
growth, which versions are used out there etc. Basically it's
something like smolt, but targeted to users/marketing, more like our
own manually-created fedoraproject.org/wiki/Statistics.

Sounds like something we'd like to have as well for Fedora?

-d


-- 
Dimitris Glezos
Jabber ID: glezos(a)jabber.org, GPG: 0xA5A04C3B
http://dimitris.glezos.com/

"He who gives up functionality for ease of use
loses both and deserves neither." (Anonymous)
--

[Jef Spaleta]

On Feb 7, 2008 8:32 AM, Dimitris Glezos <dimitris(a)glezos.com&gt; wrote:
>  Sounds like something we'd like to have as well for Fedora?

Mozilla is really lucky... the firefox application attempts to phone
home on each start up looking for addon updates as part of its normal
operation.  That consistency in phoning home makes for some very
useful stats.

We aren't that lucky.
We've absolutely no way to track livecd usage as far as I know.

I also personally think people are still turning off yum-updatesd out
of ingrained habit.
yum-updatesd is the closest thing to what mozilla has in terms of a
heartbeat.  Unfortunately yum-updatesd continues to get in the way of
people using their system and they turn it off, ruining the
consistency of our stats.  It's also complicated by the fact that when
people use a local mirror, we lose sight of them completely.  People
aren't setting up local mirrors for firefox plugins, 99.9% of firefox
users hit the mozilla servers for updates on each client start up.

What I want...what I really really want.... is a very simple heartbeat
that is on for all fedora clients by default.. that does NOT get in
the way of normal operation of anything.

This would suffice for what I need in terms of metrics:
retrieval of a specific URL at our mirrorlist server which encodes the
spin used on the client at some regular occuring time period but which
is not tied to a specific clock time.
For example have each Fedora client, by default, request the URL every
6 hours, and start this repeating process as part of boot up, so that
the time offsets from client to client will be random.  The clock
offset randomness is important statistically. I do NOT want this
heartbeat linked to an absolute time.  I do NOT want all clients in
the same timezone requesting the URL at 6:05 PM for example.

I want a client heartbeat on by default, even for live spins.  If
people want to turn it off, we should of course allow that, but it
should be opt out.

-jef

[John Poelstra]

Jeff Spaleta said the following on 02/07/2008 11:21 PM Pacific Time:

>  I also personally think people are still turning off yum-updatesd
> out
>  of ingrained habit.
>  yum-updatesd is the closest thing to what mozilla has in terms of a
>  heartbeat.  Unfortunately yum-updatesd continues to get in the way of
>  people using their system and they turn it off, ruining the
>  consistency of our stats.  It's also complicated by the fact that when 
Absolutely!  Turning off yum-updatesd is part of my rebuild script for 
new installs for the reason you've stated. I hate it :)

John

[Jef Spaleta]

On Feb 8, 2008 9:02 AM, John Poelstra <poelstra(a)redhat.com&gt; wrote:
>  Absolutely!  Turning off yum-updatesd is part of my rebuild script
> for
>  new installs for the reason you've stated. I hate it :) 

So... can we have a heartbeat process that isn't tied to update questing?

-jef

[Greg DeKoenigsberg]

On Fri, 8 Feb 2008, Jeff Spaleta wrote:

>  On Feb 8, 2008 9:02 AM, John Poelstra <poelstra(a)redhat.com&gt;
> wrote:
> > Absolutely!  Turning off yum-updatesd is part of my rebuild script for
> > new installs for the reason you've stated. I hate it :)
>
>  So... can we have a heartbeat process that isn't tied to update questing? 
In the past, this was regarded as "scary".

The reason we have a heartbeat at all is because yum-updatesd was already 
serving in this capacity, and we were able to justify piggybacking to a 
mechanism that was already there.

Myself, I'm in favor of instituting a *very* lightweight heartbeat, and 
always have been.  Put an option in firstboot to turn it off, but leave it 
on by default, and explain in the screen how important it is to the 
project, and how there's *no* personally identifiable information.  Be 
transparent about our decision, and accept the flak that we will likely 
receive as the cost of doing business.  Metrics are *extremely* important 
to our decision making abilites as a project.

Should be easy to get into F9 if we decide to do it -- but you're looking 
at a board-level decision, I think.  Fortunately, Jeff, you're on the 
board.  Also, you're extremely persuasive.  Threaten a robotic telescope 
filibuster if you don't get your way.  ;)

--g

-- 
Greg DeKoenigsberg
Community Development Manager
Red Hat, Inc. :: 1-919-754-4255
"To whomsoever much hath been given...
...from him much shall be asked"

[Jef Spaleta]

On Feb 8, 2008 9:32 AM, Greg DeKoenigsberg <gdk(a)redhat.com&gt; wrote:
>  Should be easy to get into F9 if we decide to do it -- but you're
> looking
>  at a board-level decision, I think.  Fortunately, Jeff, you're on the
>  board.  Also, you're extremely persuasive.  Threaten a robotic telescope
>  filibuster if you don't get your way.  ;) 
I'll start a heartbeat thread over to fab so the doomsayers can have
their shot at me.

-jef

[Jeroen van Meeuwen]

Jeff Spaleta wrote:
>  On Feb 7, 2008 8:32 AM, Dimitris Glezos <dimitris(a)glezos.com&gt;
> wrote:
> > Sounds like something we'd like to have as well for Fedora?
>  What I want...what I really really want.... is a very simple heartbeat
>  that is on for all fedora clients by default.. that does NOT get in
>  the way of normal operation of anything.
>   
How about smolt only submitting the hardware data if the user chooses to 
do so, and otherwise just getting it's uuid in the database, instead of 
letting the user disable it entirely?

-Jeroen

[Jef Spaleta]

On Feb 8, 2008 4:31 PM, Jeroen van Meeuwen <kanarip(a)kanarip.com&gt; wrote:
>  How about smolt only submitting the hardware data if the user chooses
> to
>  do so, and otherwise just getting it's uuid in the database, instead of
>  letting the user disable it entirely? 

Smolt right now isn't a heartbeat... it doesn't ping out often enough
to be useful for doing moving averages, and on top of that i don't
know  if it makes since for live instances.

What i want if I can get it is a heartbeat which starts at boot up and
then pings a url at 6 hour intervals. Each live spin would ping a
specific url, and all harddrive installed systems would ping a common
arch specific url.  We do a moving average of the aggregate pings and
we'll get a much better idea of the number of nat'd systems. And if we
do it right I can even estimate a NAT'd system multiplier based on the
statistics of intervals between pings over time from the same ip
address...and at no point do I expose any individual ip addresses in
the resulting output.

I'm doing this sort of stuff now using the mirrorlist hits, but i'm
pretty sure yum-updates is used by 1% of the base.

-jef

[Rahul Sundaram]

Dimitris Glezos wrote:
>  I saw this today:
>  
>    http://people.mozilla.com/~jscott/devcp/latest/
>  
>  It's a stats dashboard, showing a high level picture of the project
>  growth, which versions are used out there etc. Basically it's
>  something like smolt, but targeted to users/marketing, more like our
>  own manually-created fedoraproject.org/wiki/Statistics.
>  
>  Sounds like something we'd like to have as well for Fedora? 
That would be very nice. Just needs someone to drive that effort.

Rahul

[Max Spevack]

On Fri, 8 Feb 2008, Rahul Sundaram wrote:

> > It's a stats dashboard, showing a high level picture of the
> project 
> > growth, which versions are used out there etc. Basically it's 
> > something like smolt, but targeted to users/marketing, more like our 
> > own manually-created fedoraproject.org/wiki/Statistics. 
What I would really like to see is an automated reporting of the 
following:

Total number of people who have signed the CLA (ie: folks with Fedora 
accounts)

or

Total number of people with Edit Access on the wiki (folks in 
EditGroup).

and

Total number of Ambassadors

tracked on a monthly basis, so that a year from now we can see if we're 
growing, shrinking, and at what rate.  Maybe there are other useful 
metrics here that I am not considering as well.

If these statistics were thrown into the mapping software, that would be 
an added level of win.

Those maps have been incredibly powerful, especially when you show them 
to an executive-level manager who can understand in 10 seconds of 
looking at the map just how global Fedora is.

Would anyone like to volunteer to chat with Jef Spaleta and/or the 
Infrastructure guys about this and drive it to completion?

Good opportunity to lead a relatively small project that will have 
immediate payoff and results.

--Max