Proposal to restrict OS version to 2-3 digits in Telemetry

[Lawrence Mandel]

Bug 733452 contains a proposal to restrict the OS version to 2-3 digits in Telemetry.

As Xavier notes in the bug, currently there are 2511 OS/version combinations. This includes a very long tail with buckets of 1, which does not seem generally useful when looking at this form of aggregate data. Restricting the OS version to 3 digits will result in 152 buckets. 2 digits will result in 41 buckets. (I know, I wish it was 42 as well [1].) This change should make the data more useful in most cases.

It's of note that this bug only affects Unix variants, most notably Linux, as Windows doesn't use 3 digit version numbers.

Please follow up in the bug if you have a need to maintain the existing version buckets so that we can incorporate your use case in the decision.

Lawrence

[1] http://en.wikipedia.org/wiki/Phrases_from_The_Hitchhiker%27s_Guide_to_the_Galaxy#Answer_to_the_Ultimate_Question_of_Life.2C_the_Universe.2C_and_Everything_.2842.29

[Justin Dolske]

On 3/29/12 9:11 AM, Lawrence Mandel wrote:
> Bug 733452 contains a proposal to restrict the OS version to 2-3 digits in Telemetry.

This appears to be just for the Telemetry/metrics website, and doesn't
effect the actual collected data, right? Seems reasonable to me.

Justin

[Lawrence Mandel]

Yes. This change is only for the Telemetry Dashboard/Telemetry Evolution.

Lawrence

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Taras Glek]

On 3/29/2012 9:11 AM, Lawrence Mandel wrote:
> Bug 733452 contains a proposal to restrict the OS version to 2-3 digits in Telemetry.
>
> As Xavier notes in the bug, currently there are 2511 OS/version combinations. This includes a very long tail with buckets of 1, which does not seem generally useful when looking at this form of aggregate data. Restricting the OS version to 3 digits will result in 152 buckets. 2 digits will result in 41 buckets. (I know, I wish it was 42 as well [1].) This change should make the data more useful in most cases.
>
> It's of note that this bug only affects Unix variants, most notably Linux, as Windows doesn't use 3 digit version numbers.
>
> Please follow up in the bug if you have a need to maintain the existing version buckets so that we can incorporate your use case in the decision.

On Windows, Mac kernel versions make sense as they correspond to OS
releases. On Linux the kernel version is relatively useless for
gathering useful info about the OS(except when uname contains distro
name, but we don't report that).

As a first step I would encourage lumping all of the non-windows/non-mac
versions together under "" version.

Then a follow up we can modify telemetry reporting to:
* report actual android release
* report Linux distribution+distribution_version

Taras

[Robert Kaiser]

Taras Glek schrieb:

> Then a follow up we can modify telemetry reporting to:
> * report actual android release
> * report Linux distribution+distribution_version

Distribution + version is possibly not too easy to get everywhere, I
think it probably might make some sense to use the GTK version instead
or something like that.

Robert Kaiser

[Ted Mielczarek]

I think this is standardized as /etc/lsb-release on most modern distros.

-Ted

[Andrew Sutherland]

On 04/03/2012 11:38 AM, Ted Mielczarek wrote:
> I think this is standardized as /etc/lsb-release on most modern distros.

It looks like Fedora/RedHat is pushing /etc/os-release:
http://0pointer.de/blog/projects/os-release.html
http://www.freedesktop.org/software/systemd/man/os-release.html

Ubuntu does not appear to have it yet:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/947236
http://packages.ubuntu.com/precise/base-files

Neither does debian (and they also seem to lack lsb-release in their
base-files, although they do have /etc/debian_version, as does ubuntu,
although Ubuntu's still has debian identifiers in it):
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853
http://packages.debian.org/sid/base-files

Andrew

[Mike Hommey]

On Tue, Apr 03, 2012 at 12:41:41PM -0700, Andrew Sutherland wrote:
> On 04/03/2012 11:38 AM, Ted Mielczarek wrote:
> >I think this is standardized as /etc/lsb-release on most modern distros.

/usr/bin/lsb_release is what is standardized.

> It looks like Fedora/RedHat is pushing /etc/os-release:
> http://0pointer.de/blog/projects/os-release.html
> http://www.freedesktop.org/software/systemd/man/os-release.html

That's going to take time before being widespread enough (and I don't
mean accross distros only, it needs to be old, too, so that supporting
that only doesn't leave out older systems)

> Ubuntu does not appear to have it yet:
> https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/947236
> http://packages.ubuntu.com/precise/base-files
>
> Neither does debian (and they also seem to lack lsb-release in their
> base-files, although they do have /etc/debian_version, as does
> ubuntu, although Ubuntu's still has debian identifiers in it):
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659853
> http://packages.debian.org/sid/base-files

On Debian-based system, the lsb-release package needs to be installed.
It is installed on 80% of Debian systems reporting to popcon.debian.org.

Mike

[Robert Kaiser]

Ted Mielczarek schrieb:

> I think this is standardized as /etc/lsb-release on most modern distros.

Not so sure there is a real standard yet - and we don't only support
ultra-modern distros anyhow.

Here's what I'm seeing on my openSUSE Factory (i.e. the bleeding-edge
dev distro):

> ls -l /etc/*-release
-rw-r--r-- 1 root root 110 17. Feb 20:42 /etc/lsb-release
-rw-r--r-- 1 root root 207 14. Mär 11:46 /etc/os-release
-rw-r--r-- 1 root root 68 14. Mär 11:46 /etc/SuSE-release
> cat /etc/lsb-release
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64:core-3.2-x86_64:core-4.0-x86_64"
> cat /etc/os-release
NAME=openSUSE
VERSION="12.2 Milestone 2 (Mantis)"
VERSION_ID="12.2milestone2"
PRETTY_NAME="openSUSE 12.2 Milestone 2 (Mantis) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:12.2"
> cat /etc/SuSE-release
openSUSE 12.2 Milestone 2 (x86_64)
VERSION = 12.2
CODENAME = Mantis

I guess os-release is nearest to what could become usable, but I don't
think it's present in too many distros yet, esp. given what Andrew
replied. Also, usually, what we really need to know when we are seeing
problems are specific versions of several packages, e.g. GTK, and it's
easy to install newer versions of those packages on an older distro,
usually.

Robert Kaiser

[Justin Dolske]

"The great thing about standards is that there are so many to choose from."

Justin

[Mike Hommey]

Just use the "lsb_release" program:

# lsb_release -idrc
Distributor ID: Debian
Description: Debian GNU/Linux unstable (sid)
Release: unstable
Codename: sid

Mike

[Robert Kaiser]

Mike Hommey schrieb:

> Just use the "lsb_release" program:

Ah, didn't know that one:

> lsb_release -idrc
Distributor ID: SUSE LINUX
Description: openSUSE 12.2 Milestone 2 (x86_64)
Release: 12.2
Codename: Mantis

I wonder how far back the distros have that. Still, as mentioned before,
I'm not sure how useful this info is, given that people can easily
change which versions of GTK/X.org/etc. they are using, esp. up to newer
versions - and those versions are more relevant to use than the distro
version in the end.

Robert Kaiser