1351757 - Cease exposing SeaMonkey

Status: RESOLVED INVALID

(Socorro :: General, task)

Description

[Peter Bengtsson [:peterbe]]

The reason SeaMonkey is an option in the drop-down nav is because we pull it out from archives.mozilla.org (ftpscraper) and it into products. 

Let's stop that. And if removing it from ftpscraper isn't enough we might need to investigate how the nav works with displaying unique products. 

According to Google Analytics we have virtually 0 traffic to looking at Top Crashes for SeaMonkey. 

"Yes, consider it deprecated." --Laura Thomson


First order of business is to inform the stability list, then we can start removing it from our code.

Comment 1

[Peter Bengtsson [:peterbe]]

▶ ggrep -i SeaMonkey | grep -v test
config/crontabber.ini-dist:917:        #products=firefox, mobile, thunderbird, seamonkey
docs/development/databaseadminfunctions.rst:524:	SELECT edit_featured_versions ( 'SeaMonkey', '2.9.' );
scripts/crons/cron_libraries.sh:47:for I in Firefox Thunderbird SeaMonkey
socorro/collector/throttler.py:45:        # 100% of Thunderbird & SeaMonkey
socorro/cron/jobs/ftpscraper.py:225:        default='firefox,mobile,thunderbird,seamonkey',

(We probably won't touch socorro/collector/throttler.py since this is being replaced with Antenna)

Willkg, Does Antenna have references to SeaMonkey that we can remove?

Comment 2

[Peter Bengtsson [:peterbe]]

Actually, I don't think we should change collection with regards to SeaMonkey. 
Meaning, if a SeaMonkey Breakpad sends in a crash we should probably process it and yield a crash report index URL as before. 

Right, Lonnen?

CC willkg

Comment 3

[Will Kahn-Greene [:willkg] ET needinfo? me]

Antenna has a throttling rule that explicitly accepts SeaMonkey and Thunderbird crashes:

https://github.com/mozilla/antenna/blob/d6ac5a5d2acf99751b91b2a3ca651d99af6b9db3/antenna/throttler.py#L249

That's copied from the Socorro throttler:

https://github.com/mozilla/socorro/blob/d3cb7ebb1799cff305eaa1bdba575cbb77d0ea04/socorro/collector/throttler.py#L45

Other than that, Antenna has no SeaMonkey-specific code.

Comment 4

[Edmund Wong (:ewong)]

Hi,

As the person currently responsible with the SeaMonkey releases, I do apologize for the
lack of new releases.  The delay is due to infra pains; but we are spinning a 2.48b1 
release right now.  So will this help to extend the removal?

thanks

Comment 5

[Frank-Rainer Grahl (:frg)]

Not sure what this bug is about and why you think SeaMonkey should be removed. I am looking regularly at crash reports when users report bugs. As ewong metioned we have infrastructure problems. Beside that most crashes are either caused by bugs in Gecko code and not relevant and some high volume crashes in the mailnews component we just can't track down or reproduce.

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to Peter Bengtsson [:peterbe] from comment #0)
> According to Google Analytics we have virtually 0 traffic to looking at Top
> Crashes for SeaMonkey. 

What is "virtually zero"? Let's divide the SeaMonkey traffic by the number of SeaMonkey users, and the Firefox traffic by the number of Firefox users (in both cases multiplying them first by some suitable common order of magnitude) and compare that. What are the results? Numbers, please.

Or instead of dividing by the users, we might divide by the number of developers, since they are the people who can be expected to query the Socorro database. How many developers are there for SeaMonkey? Alas, in Firefox terms, that would amount to "virtually zero". Now in the theory of limits, zero divided by zero is one case of indetermination. So...

Then if the queries per user and the queries per developer are both several orders of magnitude lower for SeaMonkey, we'll reevaluate the situation. Let's not be too hasty.

Comment 7

[Tony Mechelynck [:tonymec]]

P.S. At least the symbol tables are now published together with all new builds, both nightlies and hourlies and both of Firefox and of SeaMonkey (and, I suppose, of Thunderbird). I can use them (not easily) but I suspect that most crashing users couldn't make head or tail of them; and of course, in order to use them you must have downloaded them together with the corresponding installable archive.

Comment 8

[Peter Bengtsson [:peterbe]]

(In reply to Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention) from comment #6)
> (In reply to Peter Bengtsson [:peterbe] from comment #0)
> > According to Google Analytics we have virtually 0 traffic to looking at Top
> > Crashes for SeaMonkey. 
> 
> What is "virtually zero"? Let's divide the SeaMonkey traffic by the number
> of SeaMonkey users, and the Firefox traffic by the number of Firefox users
> (in both cases multiplying them first by some suitable common order of
> magnitude) and compare that. What are the results? Numbers, please.
> 

We had roughly 5% visitor to the Top Crashers in the last month with product=SeaMonkey. It's actually hard to tell if it's even that, because I suspect that much of the traffic to Top Crashers reports are by our web QA automation (hence most traffic comes from Firefox v47).

Mind you some people might have Google Analytics disabled by add-ons and some people might use crash-stats.mozilla.ORG instead.

Comment 9

[Peter Bengtsson [:peterbe]]

(In reply to Frank-Rainer Grahl from comment #5)
> Not sure what this bug is about and why you think SeaMonkey should be
> removed. I am looking regularly at crash reports when users report bugs. As
> ewong metioned we have infrastructure problems. Beside that most crashes are
> either caused by bugs in Gecko code and not relevant and some high volume
> crashes in the mailnews component we just can't track down or reproduce.

It's not that we can't handle the CPU or disk load. 
We're just keeping an eye on elements that cause more distractions than value for the whole org. 

If you think there's still lots of value in having a Top Crashers, a home page, a Crashes Per Day report etc, then this bug is definitely the time to make your voices heard. Much appreciated.

Comment 10

[Peter Bengtsson [:peterbe]]

(In reply to Edmund Wong (:ewong) from comment #4)
> Hi,
> 
> As the person currently responsible with the SeaMonkey releases, I do
> apologize for the
> lack of new releases.  The delay is due to infra pains; but we are spinning
> a 2.48b1 
> release right now.  So will this help to extend the removal?
> 
> thanks

I think the problem is that our code (for the drop-down, but could be other places) specifically tries to list the featured versions, then all active versions. If there is not a single active *featured* version, that's when the home page [0] and Top Crashers [1] trips on a server error. 

I can see that there *are* some active versions
https://crash-stats.mozilla.com/api/ProductVersions/?active=true&product=SeaMonkey
But no *featured* active versions
https://crash-stats.mozilla.com/api/ProductVersions/?active=true&is_featured=true&product=SeaMonkey

Two potential solutions;

1) We have a cron job that sets featured versions automatically. It's done by frequently pulling https://product-details.mozilla.org/1.0/{productname}_versions.json E.g. https://product-details.mozilla.org/1.0/firefox_versions.json
But there is no https://product-details.mozilla.org/1.0/seamonkey_versions.json (404'ing).
I actually don't know how to get data into that but the right person to talk to would be :sylvestre

2) We can hack it so that the the web app doesn't have to rely on there being featured versions. If there is 0 featured versions, it can fall back on selecting all active versions instead. 


[0] https://crash-stats.mozilla.com/home/product/SeaMonkey
[1] https://crash-stats.mozilla.com/topcrashers/?product=SeaMonkey

Comment 11

[Edmund Wong (:ewong)]

(In reply to Peter Bengtsson [:peterbe] from comment #10)

> I think the problem is that our code (for the drop-down, but could be other
> places) specifically tries to list the featured versions, then all active
> versions. If there is not a single active *featured* version, that's when
> the home page [0] and Top Crashers [1] trips on a server error. 
> 
> I can see that there *are* some active versions
> https://crash-stats.mozilla.com/api/ProductVersions/
> ?active=true&product=SeaMonkey
> But no *featured* active versions
> https://crash-stats.mozilla.com/api/ProductVersions/
> ?active=true&is_featured=true&product=SeaMonkey
> 

Hi Peter,

I'm not very familiar with the layout of the UI as I only do the submissions
(well, the automation does the submissions, but I need to regularly
renew the token :P ).

What's the different between active and feature active and is this
something I go in and change or it's automatic? 

Will the new (soon-to-be-released-someday) 2.48b1 alleviate this issue or
will it just hide it until a later date when it re-appears?

> 1) We have a cron job that sets featured versions automatically. It's done
> by frequently pulling
> https://product-details.mozilla.org/1.0/{productname}_versions.json E.g.
> https://product-details.mozilla.org/1.0/firefox_versions.json
> But there is no
> https://product-details.mozilla.org/1.0/seamonkey_versions.json (404'ing).
> I actually don't know how to get data into that but the right person to talk
> to would be :sylvestre

I've never seen this file or this url in all these years, so either it's
something automatic that's no longer automatic (i.e. broken) on our side,
or it is manual but the person who does it no longer does it anymore.

> 
> 2) We can hack it so that the the web app doesn't have to rely on there
> being featured versions. If there is 0 featured versions, it can fall back
> on selecting all active versions instead. 

If 2.48b1 and a more-regular-release fixes this, then there's no need
for hacking; but since I'm the only one who's doing this, there is always
a chance that I slip.  So would it be possible to modify it such that
it selects all the active versions?  Furthermore, is this code available
so that I might fix this myself since this is theoretically my fault.

Thanks!

Comment 12

[Edmund Wong (:ewong)]

(In reply to Edmund Wong (:ewong) from comment #11)

> > 
> > 2) We can hack it so that the the web app doesn't have to rely on there
> > being featured versions. If there is 0 featured versions, it can fall back
> > on selecting all active versions instead. 
> 
> If 2.48b1 and a more-regular-release fixes this, then there's no need
> for hacking; but since I'm the only one who's doing this, there is always
> a chance that I slip.  So would it be possible to modify it such that
> it selects all the active versions?  Furthermore, is this code available
> so that I might fix this myself since this is theoretically my fault.


Never mind.. found the source..  

I might not have enough cycles to fix this since I need to familiarize
myself (again) with django and this code.

Comment 13

[Edmund Wong (:ewong)]

Having chatted with :Sylvestre over irc, I've discovered that the items in production-
details.mo was generated by ship-it and since SeaMonkey doesn't use ship-it, 
there won't be a seamonkey_version.json file there.

I believe SeaMonkey isn't permitted/allowed/able to be included in Ship-it.

So, there needs to be an alternative way; that is, setting the active version ui-item to
list all versions instead.

though I'm not sure anyone's going to accept something as specific to SeaMonkey.

Comment 14

[Peter Bengtsson [:peterbe]]

If SeaMonkey can't be in ship-it, then I suspect the easiest solution right now is to simply change the logic so that the UI doesn't *require* that featured versions are set. I'd be happy to solve for this as this would continue to give you graphs and reports in Crash-Stats for SeaMonkey. 


By the way, Featured versions predates me but the idea was basically to answer of "Of all the active versions [41 at the time of writing], which ones should be in the graph on the home page? And which ones should be listed higher up in the "Versions" drop-down in the nav".

Second by the way, featured versions, in the case of Firefox, isn't just 4 most "hottest" versions. It's a way to point to which is the latest version in the Nighlty, Aurora, Beta and Release channels.

Comment 15

[Peter Bengtsson [:peterbe]]

So, see https://bugzilla.mozilla.org/show_bug.cgi?id=1352385 which already has as PR attached to. 

With this we can make this discussion a lot easier. Now home page, Top Crashers, Crashes per Day will work for products that have active versions but not featured versions.

Comment 16

[Peter Bengtsson [:peterbe]]

Clearly interest in navigating the webapp around the SeaMonkey product exists. Thanks for standing up!

The UI bugs (3) that happened only for SeaMonkey are now all fixed due to a solution where we used the top 4 active versions instead of featured versions. 

(PS. The fixes have been tested in Stage and will roll out to prod later today)

Comment 17

[Frank-Rainer Grahl (:frg)]

Thanks. I use it now and then mostly after after a new release or when I see some problems discussed in newsgroups and I am glad that its available.

Comment 18

[Edmund Wong (:ewong)]

(In reply to Peter Bengtsson [:peterbe] from comment #16)
> Clearly interest in navigating the webapp around the SeaMonkey product
> exists. Thanks for standing up!
> 
> The UI bugs (3) that happened only for SeaMonkey are now all fixed due to a
> solution where we used the top 4 active versions instead of featured
> versions. 
> 
> (PS. The fixes have been tested in Stage and will roll out to prod later
> today)

Thanks Peter!  Appreciate the help with this bug.

Edmund

Comment 19

[[github robot]]

Commit pushed to master at https://github.com/mozilla-services/socorro

https://github.com/mozilla-services/socorro/commit/a5f9a0525db5a5878ad23556662f0ff75e1f5e16
Restoring SeaMonkey to list of expected products (#4024)

Bug 1351757 was resolved as invalid, and the SeaMonkey product is expected in the list.