Closed
Bug 788887
Opened 12 years ago
Closed 12 years ago
[socorro-crashstats] centralize list of OS names/versions
Categories
(Socorro :: Webapp, task)
Socorro
Webapp
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rhelmer, Assigned: rhelmer)
References
Details
There are OS names such as lin/win/mac and "Windows", "Mac OS X" and "Linux" as well as versions ("Windows XP", etc) spread across the DB, middleware code, and the django model/view code.
In some HTML templates there's only room for three OSes, so I propose that we just do something simple like this in the settings/local.py:
{'OS':
{'Windows':
'versions': ['NT', '...']},
{'Mac OS':
'versions': ['10.6', '...']},
{'Linux':
'versions': ['2.4.x', '...']}}
Views that currently expect these to be exactly 3 can assert that for now, although being generic here would be better, I think that means we'd need to be more clever in terms of data visualization (adding an extra 10 columns to e.g. existing TCBS HTML table seems unpalatable).
Comment 1•12 years ago
|
||
FWIW, the postgres database has the table OS_Versions, which is fairly comprehensive and constantly updated. There's also the table os_names, which has the three-letter abbreviations for each OS.
Assignee | ||
Comment 2•12 years ago
|
||
(In reply to [:jberkus] Josh Berkus from comment #1)
> FWIW, the postgres database has the table OS_Versions, which is fairly
> comprehensive and constantly updated. There's also the table os_names,
> which has the three-letter abbreviations for each OS.
What is the source for these tables? We'd need this to be static and not updated from user input e.g. crash data.
Comment 3•12 years ago
|
||
Well, if you need it to be static, then including OS versions in your list seems foolhardy.
Assignee | ||
Comment 4•12 years ago
|
||
(In reply to [:jberkus] Josh Berkus from comment #3)
> Well, if you need it to be static, then including OS versions in your list
> seems foolhardy.
That's a good point - we could do validation on them I suppose.
It'd probably be best to have a single function that loads the OS info, instead of leaving it all up to the views...
Assignee | ||
Comment 5•12 years ago
|
||
(In reply to Robert Helmer [:rhelmer] from comment #4)
> (In reply to [:jberkus] Josh Berkus from comment #3)
> > Well, if you need it to be static, then including OS versions in your list
> > seems foolhardy.
>
> That's a good point - we could do validation on them I suppose.
>
> It'd probably be best to have a single function that loads the OS info,
> instead of leaving it all up to the views...
If we have to have a "top three" OSes (for certain views) perhaps that should live in config, and the full list available via mware?
Assignee | ||
Updated•12 years ago
|
Summary: centralize list of OS names/versions → [socorro-crashstats] centralize list of OS names/versions
Assignee | ||
Comment 6•12 years ago
|
||
Ugh, this is really inconsistent. Sometimes Windows is called "Windows NT" and sometimes it's "Windows", for instance.
The current TCBS service returns things like "win_count", "linux_count" and "mac_count".
I am not sure if this is really worth papering over in the views and templates right now, I am considering leaving it alone for the initial version and revisiting this in a future release.
Assignee | ||
Comment 7•12 years ago
|
||
Might as well start something:
https://github.com/mozilla/socorro-crashstats/pull/79
Future work would be things like:
* capturing all variations of OS names
* adding mware service to return all OS names and versions (we still need a way of specifying the "top 3" as long as the templates are implemented the way they are though, so I think the config could stay as-is)
Note that I added it to all appropriate views but only actually used it in the topcrashers.html template, since there are outstanding bugs and PRs for the other pages that need this (can handle that in review once this lands on master)
Assignee | ||
Updated•12 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•