Upgrade metrics

[Axel Thimm]

On Fri, Jun 15, 2007 at 08:54:53AM -0500, Mike McGrath wrote:
> Axel Thimm wrote:
> >Hi,
> >
> >is it possible to create some relative metrics of release upgrades,
> >e.g. FC5 -> FC6, FC5 -> F7?
> >
> >  
> We didn't really start taking metrics until FC6.

Yes, I know, I was just giving examples of where it would had been
useful in today's context. Testing 13 month life span would probable
be better done in the F8 release time, e.g. checking how many FC6
users really upgrade to F8 skipping one release (which is what the 13
month span was about).

If we need FC6 to send out more info in some way (smolt, yum http
agent etc) we should implant that early in both FC6 and F7, so we know
in autumn what people are really doing (always in relative numbers,
e.g. FC6->F8 upgrades in comparison to F7->F8 upgrades and F8 install
from scratch)

> >The interesting part is to create a graph over time to answer the
> >question whether the 13 month EOL is really paying off. And perhaps on
> >base of that graph one could revise this decision. At the very leats
> >it would be interesting to notice the upgrade behaviour of Fedora
> >users.
> >
> >I have no idea how to do that other than marking the HTTP Agent of yum
> >on F<N> accordingly, as well as the HTTP Agent in anaconda's yum
> >(noting fresh installs vs upgrades). Worth to add this for F8?
> >  
> >  
> So here's a graph of the smolt vs yum ip stuff:
> 
> https://admin.fedoraproject.org/cacti/graph.php?action=view&rra_id=all&local_graph_id=253

Nice graph! This gives us an estimate of absolute numbers, but not yet
upgrades vs bare metal installs. It nicely shows that smolt and
yum data are coherent.

> The problem with the smolt numbers is that anyone doing kickstarts, 
> installing via runlevel 3, yum upgrades or anaconda upgrades will never 
> get prompted to enable smolt and there are privacy concerns just 
> enabling it by default.

That doesn't matter, we won't get everyone and there will be an
unknown dark factor. But the numbers we get can be divided to remove
that unknown constant, e.g. create relative numbers. For example:

"In the first 4 weeks after the release of F8 and until EOL of FC6 we
saw that:

   70% did a bare metal install
   20% upgraded from F7
    9% upgraded from FC6
    1% did something else (like upgrading from RHL9)"

These are the numbers we would need to justify a 13 month EOL time
including all efforts that go with it, or whether it wasn't worth it
because say only 1% would make really use for FC6->F8 upgrades and we
better invest that man time into something else.

also if these numbers can be seen over time we can spot when the user
do the bare metal installs and the upgrades. I would guess that after
a release one would have a large bare-metal-install peak and some time
after that the upgrades would slowly grow as well.

> The scary thing is I still regularly get requests regarding Fedora
> Core 1!!  (we moved it from the primary mirror to
> http://archives.fedoraproject.org/fedora/linux/core/1/ and that
> brought some people out of the woodwork)

Wow, that's really scary. FC1 should of course live forever in
archives.fp.o for historical reason, but actually using it is really
questionable :)
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-infrastructure-list/attachments/20070615/ad51e5a2/attachment.sig>