Closed Bug 1260420 Opened 8 years ago Closed 8 years ago

crash-stats home page should automatically update the featured versions

Categories

(Socorro :: Webapp, task)

Product:
Socorro
Component:
Webapp
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: calixte, Assigned: peterbe)

References

(
URL
)

Details

Attachments

(1 file)

Link to Github pull-request: https://github.com/mozilla/socorro/pull/3537
44 bytes, text/x-github-pull-request
Details | Review 
For example, right now info about 45.0 are provided rather than 45.0.1 which is the current release version.
Kairo usually handles that. I changed it to 45.0.1 for 45. It takes up up to 1 hour for the caches to invalidate for the stuff on the home page.
Assignee: nobody → peterbe
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Calixte meant "we need automation here", it should not be a manual process. Same for beta
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: crash-stats home page should provides info about current versions → crash-stats home page should automatically update the versions
Automation would be awesome. I wonder Kairo thinks since he's the one "suffering" from the manual labor. 

Not entirely sure I understand what "featured" means from a releng point of view. 

We could either entirely remove this thing called "featured" as a piece of data and instead just calculate on the fly which 4 versions should be shown on the home page. 
Or we can have a cron job that figures it out and set it. Basically a kairo-bot.
I'm generally in favor of this. We bring it up once a year or so, and KaiRo has been very opposed.
The data are outdated (I was waiting for bug 1234832 which has been implemented) but this file will provide the actual versions:
https://product-details.mozilla.org/firefox_versions.json
Depends on: 1234832
I'd be happy to write a crontabber app that reads that URL and updates featured versions accordingly. 
But I'm not familiar with Kairo's argument against automation and would like to hear it.
Flags: needinfo?(kairo)
He explained in bug 1212314
Flags: needinfo?(kairo)
I do not want this to be automated unless we can / want to depend on a tool that knows what actually *shipped* and not just what was built. Ideally, we only want things to show up here about a day after it was actually shipped, i.e. as soon as we actually have data of the build that shipped, but right after it shipped would be OK as well. Note that this definition of "shipped" may include things like "we turned on updates for this Aurora version".
Of course we have this information... Example: the download pages on the website
Well, we'd need the information in a nicely machine-readable format for sure.

But yes, I guess with a crontabber app we could do it based on what Sylvestre has described once that works well - and we'd need to put some intelligence in there about e.g. our generic "rapid beta" version, but that should be doable. That said, this solution will only work for Firefox and FennecAndroid, and not for any other products, I guess.
And I wonder if that is worth the work put into it as doing it on the Admin page is nice and fast, the only annoying thing there is that the page requires at least one featured version to be set for all products in the list and we have some products on there that we actually need to retire but which happen to block me from submitting before I set a bogus features version for them.
Please stop bikeshedding. We do need to stop doing manual work when this can be automated quite easily.
(In reply to Sylvestre Ledru [:sylvestre] from comment #11)
> Please stop bikeshedding. We do need to stop doing manual work when this can
> be automated quite easily.

Automation is awesome and always a win but...

* We're not bleeding of pain right now
* Is the API endpoint that our crontabber app would read ready at all?
* Let's postpone till Kairo comes back and manages to catch up with his inbox.
(In reply to Sylvestre Ledru [:sylvestre] from comment #11)
> Please stop bikeshedding. We do need to stop doing manual work when this can
> be automated quite easily.

There's no bikeshedding, and I have already said I'm good with automation if the work to do automation is actually less than the work for setting it manually a few times per year, and if we can automate it in a way that puts the "right" versions there.

(In reply to Peter Bengtsson [:peterbe] from comment #12)
> * We're not bleeding of pain right now
> * Is the API endpoint that our crontabber app would read ready at all?

That's exactly what I was pointing to.

> * Let's postpone till Kairo comes back and manages to catch up with his
> inbox.

Just FTR, I *am* back and my comment were part of catching up, which I have mostly completed now. :)
> * Is the API endpoint that our crontabber app would read ready at all?
Yes, and has been for several years:
http://viewvc.svn.mozilla.org/vc/libs/product-details/json/firefox_versions.json?view=co&content-type=text%2Fplain

We are working on https://product-details.mozilla.org/firefox_versions.json which should be live soon (less than a couple weeks I hope).
(In reply to Sylvestre Ledru [:sylvestre] from comment #14)
> We are working on https://product-details.mozilla.org/firefox_versions.json
> which should be live soon (less than a couple weeks I hope).

That would be a great step to build on for being able to automate things like this, for sure.

As a nit, are you planning on having an end point for underlying service that is using less legacy (and easier to understand) variable/field names?
(In reply to Sylvestre Ledru [:sylvestre] from comment #14)
> > * Is the API endpoint that our crontabber app would read ready at all?
> Yes, and has been for several years:
> http://viewvc.svn.mozilla.org/vc/libs/product-details/json/firefox_versions.
> json?view=co&content-type=text%2Fplain
> 
> We are working on https://product-details.mozilla.org/firefox_versions.json
> which should be live soon (less than a couple weeks I hope).

Where is nightly? I.e. - at the time of writing - 48.0a1.

Will this be available when the work on product-details.m.o is complete?

Can we put a dependency on this bug to the bug about finishing product-details.m.o and its inclusion of the nightly version.
See Also: → 1196873
(In reply to Peter Bengtsson [:peterbe] from comment #16)

> Where is nightly? I.e. - at the time of writing - 48.0a1.
> 
> Will this be available when the work on product-details.m.o is complete?
This is fixed now:
https://product-details.mozilla.org/mobile_versions.json
https://product-details.mozilla.org/firefox_versions.json
At the time of writing, on https://crash-stats.mozilla.com/home/product/Firefox we feature "50.0b" which NOT available in https://product-details.mozilla.org/1.0/firefox_versions.json
But we could get that from taking "LATEST_FIREFOX_DEVEL_VERSION" (which is currentl 50.0b2) and chop off the number after the 'b'.
Is that right?
Flags: needinfo?(sledru)
I think we want the last beta and not all.
Ritu, Liz, do you agree?
Flags: needinfo?(sledru)
Flags: needinfo?(rkothari)
Flags: needinfo?(lhenry)
The "featured" beta is the one that ends up on the graph at https://crash-stats.mozilla.org/home/product/Firefox.  So I think it is still useful to show an overall rate for 50.0b (even though that isn't really the name of a product).     If we showed the latest beta as the "featured" one the graph would be confusing to people (it would always look like a recent spike) 

When I look at top crashing bugs for beta, I am normally looking at the latest beta, or the latest few, and never care about the average across betas.
Flags: needinfo?(lhenry)
I want to make a slightly different suggestion here for what gets displayed on the crash-stats main page. 

I think we need two graphs, with different scales. We need 1) for Nightly and Aurora and 2) for Beta and Release channels. Because of the unsubmitted crash reports on these Nightly and Aurora channels, the crash rates are in the really high range of 7-30. The crash reports for Beta and Release typically are 1-3 range. Combining all 4 channels in one graph makes the beta and release crash rate trends insignificantly small and spikes/dips are hard to discern.
Flags: needinfo?(rkothari)
(In reply to Ritu Kothari (:ritu) from comment #22)
> I want to make a slightly different suggestion here for what gets displayed
> on the crash-stats main page. 

I've filed bug 1306831 for this suggestion, to keep this bug focused on the displayed
versions.
So, if I get it right, Liz is saying Yes to my question. Ritu, off topic, https://bugzilla.mozilla.org/show_bug.cgi?id=1306831 :)

I can't get started on this until I get a clear answer on https://bugzilla.mozilla.org/show_bug.cgi?id=1260420#c19
(In reply to Peter Bengtsson [:peterbe] from comment #24)
> I can't get started on this until I get a clear answer on
> https://bugzilla.mozilla.org/show_bug.cgi?id=1260420#c19

Yes, that's correct.
Wayne,

The context of this bug is that we're trying to remove the manual process of using the Socorro admin interface to set the "featured versions". 

I've got a prototype that reads the *_versions.json files from https://product-details.mozilla.org/1.0/
It makes sense for the sake of Firefox and FennecAndroid (aka. mobile) but for Thunderbird, the versions are very different.

In https://product-details.mozilla.org/1.0/thunderbird_versions.json:

* 51.0a2
* 50.0b1
* 45.4.0

But on https://crash-stats.mozilla.com/home/product/Thunderbird you have:

* 52.0a1
* 51.0a2
* 45.4.0

Which is right? 

If you want to, I can *exclude* Thunderbird from this new crontabber app I'm writing and only update the featured versions for Firefox and FennecAndroid. (...and let you continue to manually maintain the featured versions)
Flags: needinfo?(vseerror)
(In reply to Peter Bengtsson [:peterbe] from comment #26)
> Wayne,
> 
> The context of this bug is that we're trying to remove the manual process of
> using the Socorro admin interface to set the "featured versions". 
> 
> I've got a prototype that reads the *_versions.json files from
> https://product-details.mozilla.org/1.0/
> It makes sense for the sake of Firefox and FennecAndroid (aka. mobile) but
> for Thunderbird, the versions are very different.
> 
> In https://product-details.mozilla.org/1.0/thunderbird_versions.json:
> 
> * 51.0a2
> * 50.0b1
> * 45.4.0
> 
> But on https://crash-stats.mozilla.com/home/product/Thunderbird you have:
> 
> * 52.0a1
> * 51.0a2
> * 45.4.0
> 
> Which is right? 
> 
> If you want to, I can *exclude* Thunderbird from this new crontabber app I'm
> writing and only update the featured versions for Firefox and FennecAndroid.
> (...and let you continue to manually maintain the featured versions)

Or, perhaps direct our energy to fix the content of https://product-details.mozilla.org/1.0/thunderbird_versions.json
Kevin,

My proposed patch automates away the setting of "feature versions" for Firefox, FennecAndroid and Thunderbird. 
Sylvestre et. al. is confident this is the right thing to do for Firefox. 

But for FennecAndroid, do you agree? Or do you prefer to manually maintain the list of featured versions?
To avoid having to read the whole bug, just read comment #26 to Wayne and imagine it for FennecAndroid.
Flags: needinfo?(kbrosnan)
Setting versions is tedious +1 to automating this. Though there are times when FennecAndroid does not match desktop. FennecAndroid does not do b99 for example and there are times when we do a point release on Firefox desktop and not on FenencAndroid. Will there be a way to override if it is wrong?
Flags: needinfo?(kbrosnan)
(In reply to Kevin Brosnan [:kbrosnan] from comment #30)
> Setting versions is tedious +1 to automating this. Though there are times
> when FennecAndroid does not match desktop. FennecAndroid does not do b99 for
> example and there are times when we do a point release on Firefox desktop
> and not on FenencAndroid. Will there be a way to override if it is wrong?

Looks like we have a specific file for Mobile: https://product-details.mozilla.org/1.0/mobile_versions.json.
(In reply to Marco Castelluccio [:marco] from comment #31)
> (In reply to Kevin Brosnan [:kbrosnan] from comment #30)
> > Setting versions is tedious +1 to automating this. Though there are times
> > when FennecAndroid does not match desktop. FennecAndroid does not do b99 for
> > example and there are times when we do a point release on Firefox desktop
> > and not on FenencAndroid. Will there be a way to override if it is wrong?
> 
> Looks like we have a specific file for Mobile:
> https://product-details.mozilla.org/1.0/mobile_versions.json.

There will not be a way to override it. The admin pages will effectively be useless. If you override something, the cron job will just override that almost immediately.
I don't care about overrides since fennecandroid gets its own source of truth. My only concern was that the data was going to come from desktop Firefox. Great to see this happen!
(In reply to Peter Bengtsson [:peterbe] from comment #27)
> ...
> Or, perhaps direct our energy to fix the content of
> https://product-details.mozilla.org/1.0/thunderbird_versions.json

I am happy to see automation for Thunderbird. There is one issue (which I'm not sure whether it will be better or worse with automation) - our effective release dates sometimes lag signficantly, so tend to "too quickly" lose past version numbers, particularly for topcrash and crashes-per-day. It's always been a sticking point with me, so it would be nice if we didn't lose them so quickly.

That said, what ontent if any is missing from https://product-details.mozilla.org/1.0/thunderbird_versions.json ?
Flags: needinfo?(vseerror)
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #34)
> (In reply to Peter Bengtsson [:peterbe] from comment #27)
> > ...
> > Or, perhaps direct our energy to fix the content of
> > https://product-details.mozilla.org/1.0/thunderbird_versions.json
> 
> I am happy to see automation for Thunderbird. There is one issue (which I'm
> not sure whether it will be better or worse with automation) - our effective
> release dates sometimes lag signficantly, so tend to "too quickly" lose past
> version numbers, particularly for topcrash and crashes-per-day. It's always
> been a sticking point with me, so it would be nice if we didn't lose them so
> quickly.
> 

You mean the sunset date is coming up too soon? That's orthogonal but something that could be fixed. ...in a different bug. 


> That said, what ontent if any is missing from
> https://product-details.mozilla.org/1.0/thunderbird_versions.json ?

You tell me :)

My patch (https://github.com/mozilla/socorro/pull/3537) just takes ALL the versions mention for https://product-details.mozilla.org/1.0/thunderbird_versions.json and sets them to be the featured versions.
(In reply to Peter Bengtsson [:peterbe] from comment #35) 
> 
> > That said, what ontent if any is missing from
> > https://product-details.mozilla.org/1.0/thunderbird_versions.json ?
> 
> You tell me :)

Firefox raw data has each on a separate lines. Is it possible to do that for Thunderbird?

In that format, we current have 
{"LATEST_THUNDERBIRD_VERSION": "45.4.0", 
 "LATEST_THUNDERBIRD_DEVEL_VERSION": "50.0b1", 
 "LATEST_THUNDERBIRD_ALPHA_VERSION": "51.0a2"
}
which is considerably different from 
{ "FIREFOX_NIGHTLY": "52.0a1",
  "FIREFOX_AURORA": "51.0a2",
  "FIREFOX_ESR": "45.4.0esr",
  "FIREFOX_ESR_NEXT": "",
  "LATEST_FIREFOX_DEVEL_VERSION": "50.0b8",
  "LATEST_FIREFOX_OLDER_VERSION": "3.6.28",
  "LATEST_FIREFOX_RELEASED_DEVEL_VERSION": "50.0b8",
  "LATEST_FIREFOX_VERSION": "49.0.1"
}

Thunderbird is missing NIGHTLY, currently 52.0a1. 
And, how is the designation "LATEST_" different from the entries without it (which Thunderbird has none of)?
i.e. it seems inconsistent.  Is it just historical carryover?
Summary: crash-stats home page should automatically update the versions → crash-stats home page should automatically update the featured versions
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #36)
> Thunderbird is missing NIGHTLY, currently 52.0a1.

I filed bug 1311327 for adding Nightly to the Thunderbird data, which I believe is the only thing needed by Peter to automatically set the Thunderbird featured versions.
Depends on: 1311327
Commit pushed to master at https://github.com/mozilla/socorro

https://github.com/mozilla/socorro/commit/39aab49bacf5832b8cd2c8d99bee558e315a4f89
bug 1260420 - set featured versions by product-defails.m.o (#3537)

* bug 1260420 - set featured versions by product-defails.m.o

* review feedback addressed

* fix broken test
Blocks: 1312731
Call me paranoid but I've now enabled this on stage (https://crash-stats.allizom.org) and I would like to see it work there at least once before we enable this in prod. 

Stage used to get its featured versions from querying the API https://crash-stats.mozilla.com/api/ProductVersions/?featured=true but now it's using this new crontabber app instead. 

So can you please keep an eye out to see if stage changes its featured versions correctly when you make a change to the content of https://product-details.mozilla.org/1.0/

For the record, here's a snapshot (as of 10 seconds ago) of the featured versions on stage:
https://gist.github.com/peterbe/a17c33caa82d31c357daaedb309d36f8
https://crash-stats.allizom.org/home/product/Thunderbird does not have correct feature versions - missing 52.0a1 - reflecting the contents of https://product-details.mozilla.org/1.0/thunderbird_versions.json 

https://crash-stats.allizom.org/crashes-per-day/?p=Thunderbird does have correct feature versions - 52.0a1, 51.0a2, 50.0b2, 45.4.0
(In reply to Wayne Mery (:wsmwk, NI for questions) from comment #40)
> https://crash-stats.allizom.org/home/product/Thunderbird does not have
> correct feature versions - missing 52.0a1 - reflecting the contents of
> https://product-details.mozilla.org/1.0/thunderbird_versions.json 
> 
> https://crash-stats.allizom.org/crashes-per-day/?p=Thunderbird does have
> correct feature versions - 52.0a1, 51.0a2, 50.0b2, 45.4.0

Strange but I suspect the delays tripped us. 

At the time of writing, this is what we have in the stage database:

breakpad=> select version_string, featured_version from product_versions where product_name='Thunderbird' and featured_version=true order by version_sort desc limit 10;
 version_string | featured_version
----------------+------------------
 51.0a2         | t
 50.0b3         | t
 45.4.0         | t
(3 rows)

That matches https://product-details.mozilla.org/1.0/thunderbird_versions.json

The crontabber app that updates the version runs only every 1 hour. Then on the webapp, a lot of things are cached for 1 hour. So, the worst case scenario is 2 hours. 

However you wrote your comment 14 hours ago (at the time of writing) but I just checked the crontabber.log and it was only just now in the latest run that it changed from 50.0b2 to 50.0b3

[centos@ip-172-31-10-19 ~]$ grep 'Set featured versions' /var/log/socorro/crontabber.log | grep Thunderbird
2016-10-31 04:00:06,970 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 05:00:14,119 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 06:05:05,855 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 07:05:06,184 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 08:05:06,361 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 09:10:06,249 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 10:15:05,853 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 11:15:06,540 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 12:20:06,183 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 13:25:06,442 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 14:30:06,884 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 15:35:05,710 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b2, 51.0a2
2016-10-31 16:40:05,642 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b3, 51.0a2
[centos@ip-172-31-10-19 ~]$ date
Mon Oct 31 16:57:35 UTC 2016


In conclusion, all is working as expected.
Blocks: 1315340
Has any changes been made to firefox_version.json recently that we can followup and check that they worked on stage? I.e. 
https://crash-stats.allizom.org/api/ProductVersions/?is_featured=true&product=Firefox
Flags: needinfo?(rkothari)
Flags: needinfo?(lhenry)
We released beta 12 for fennec
For Firefox, we don't manage RC in pd yet :(
Flags: needinfo?(rkothari)
Flags: needinfo?(lhenry)
Cool! So https://product-details.mozilla.org/1.0/mobile_versions.json and seems to match https://crash-stats.allizom.org/api/ProductVersions/?is_featured=true&product=FennecAndroid
In particular, they both have 50.0b12

I understand the sentence ("For Firefox, we don't manage RC in pd yet") but I don't know what really means. 
Does that mean that `LATEST_FIREFOX_VERSION` in https://product-details.mozilla.org/1.0/firefox_versions.json doesn't increment when new release versions are put out? 
If so, that means we still can't rely on product-details.mozilla.org.

Please note that when we switch on this cron job solution in prod, there is NO manual process to set featured versions.
(In reply to Peter Bengtsson [:peterbe] from comment #45)
> I understand the sentence ("For Firefox, we don't manage RC in pd yet") but
> I don't know what really means. 
> Does that mean that `LATEST_FIREFOX_VERSION` in
> https://product-details.mozilla.org/1.0/firefox_versions.json doesn't
> increment when new release versions are put out? 
> If so, that means we still can't rely on product-details.mozilla.org.

For the Firefox featured versions, it doesn't really matter because we always show 50.0b, not the individual build (and RCs are 50.0b99, so they are considered when you use version=50.0b).
I'm not exactly sure what will happen when we mark 47.0.2 as shipped (we shipped a dot release to an older branch).  It might show up on your "featured" list.
As Marco says, the RCs not being in product details shouldn't matter -- they only happen at the end of a cycle on desktop, when we build the last release candidate(s) for a beta cycle from the mozilla-release repo and then ship it on the beta channel.  It won't matter for crash-stats !
The Thunderbird JSON file has been updated today (a few minutes ago) with 52.0a1, and I see that crash-stats has picked up the changes.
I'd say this is working as expected.
This has now been deployed on prod too. Here's what the log output was on its first run:

2016-11-09 16:20:07,423 DEBUG - MainThread -  - MainThread - about to run <class 'socorro.cron.jobs.featured_versions_automatic.FeaturedVersionsAutomaticCronApp'>
2016-11-09 16:20:07,874 INFO - MainThread -  - MainThread - Set featured versions for Firefox to: 49.0.2, 50.0b, 51.0a2, 52.0a1
2016-11-09 16:20:07,997 INFO - MainThread -  - MainThread - Set featured versions for FennecAndroid to: 49.0.2, 50.0b12, 51.0a2, 52.0a1
2016-11-09 16:20:08,127 INFO - MainThread -  - MainThread - Set featured versions for Thunderbird to: 45.4.0, 50.0b3, 51.0a2
2016-11-09 16:20:08,129 DEBUG - MainThread -  - MainThread - successfully ran <class 'socorro.cron.jobs.featured_versions_automatic.FeaturedVersionsAutomaticCronApp'> on 2016-11-09 16:20:07.463146+00:00
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
(In reply to Peter Bengtsson [:peterbe] from comment #49)
> This has now been deployed on prod too. Here's what the log output was on
> its first run:
> 
> 2016-11-09 16:20:07,423 DEBUG - MainThread -  - MainThread - about to run
> <class
> 'socorro.cron.jobs.featured_versions_automatic.
> FeaturedVersionsAutomaticCronApp'>
> 2016-11-09 16:20:07,874 INFO - MainThread -  - MainThread - Set featured
> versions for Firefox to: 49.0.2, 50.0b, 51.0a2, 52.0a1
> 2016-11-09 16:20:07,997 INFO - MainThread -  - MainThread - Set featured
> versions for FennecAndroid to: 49.0.2, 50.0b12, 51.0a2, 52.0a1
> 2016-11-09 16:20:08,127 INFO - MainThread -  - MainThread - Set featured
> versions for Thunderbird to: 45.4.0, 50.0b3, 51.0a2
> 2016-11-09 16:20:08,129 DEBUG - MainThread -  - MainThread - successfully
> ran <class
> 'socorro.cron.jobs.featured_versions_automatic.
> FeaturedVersionsAutomaticCronApp'> on 2016-11-09 16:20:07.463146+00:00

It looks like Thunderbird Nightly is missing?
It is present in https://product-details.mozilla.org/1.0/thunderbird_versions.json.
(In reply to Marco Castelluccio [:marco] from comment #50)
> 
> It looks like Thunderbird Nightly is missing?
> It is present in
> https://product-details.mozilla.org/1.0/thunderbird_versions.json.

yeah 
https://crash-stats.mozilla.com/home/product/Thunderbird
Flags: needinfo?(peterbe)
Pretty sure LATEST_THUNDERBIRD_NIGHTLY_VERSION was added to https://product-details.mozilla.org/1.0/thunderbird_versions.json at a later date. 
It was not an option when I wrote the code https://github.com/mozilla/socorro/blob/master/socorro/cron/jobs/featured_versions_automatic.py#L116-L119

Let's file a new bug specifically for Thunderbird nightly.
Flags: needinfo?(peterbe)
See Also: → 1316427
It was added on 2016-11-05. I mentioned I saw Thunderbird Nightly on crash-stats, so I thought you already added it (see comment 48), but I guess what I saw was the manual featured version (since this change was still on stage).
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: