978792 - retain Thunderbird processed crashes longer than 12 months

Status: RESOLVED WONTFIX

(Socorro :: Database, enhancement)

Description

[Wayne Mery (:wsmwk)]

I query occasionally to find regression ranges of Thunderbird crashes. The current example is a crash bug recently filed that might trace back to TB16 released fall 2012. If I could query crashes going back, say perhaps 2 years, I might probably be able to find the regression range. But I don't have a precise retention period in mind. And, I am open to alternative methods/data sources to find what I need.

(I don't want this to sound like a sob story) 
One or more of the following can make Thunderbird crash regression hunting difficult
- some TB crashes occur at a low rate in releases
- even harder in non-release builds because we have relatively low numbers of beta users ...
- because we have so few volunteers filing crash bugs and doing the detective work
And lastly, because Thunderbird is not fast release and does ESR only since version 17 fall 2012, we are now dealing with very long time frames for each release.

per IRC 
- (laura) https://mana.mozilla.org/wiki/display/websites/Socorro+Data+Expiration+Policy in part states "If non-Firefox projects have longer needs (please let me know) that may be okay, depending on how hard that is to implement. I believe for now we're going to delete everything over a year old until we get some infrastructure in place for the granularity we want."
- (kairo) raw crashes are kept 6 months, processed crashes for release 12 months, stuff on the crash-analysis server and the crashes/ADU summary data is being kept indefinitely

xref bug 978782

Comment 1

[Robert Kaiser]

(In reply to Wayne Mery (:wsmwk) from comment #0)
> And lastly, because Thunderbird is not fast release and does ESR only since
> version 17 fall 2012, we are now dealing with very long time frames for each
> release.

Well, that's questionable, as after all a single version isn't alive for a year, there's security updates every 6 weeks. And regression finding on release is always pretty wonky. But I won't question your practices, after all IMHO nothing is as old as the software from yesterday. What I care about is that any changes to comfort you are not making things more complicated, unstable or expensive for uses of anything with "Firefox" in its brand name.

Comment 2

[Wayne Mery (:wsmwk)]

(In reply to Robert Kaiser (:[e-mail]) from comment #1)
> (In reply to Wayne Mery (:wsmwk) from comment #0)
> > And lastly, because Thunderbird is not fast release and does ESR only since
> > version 17 fall 2012, we are now dealing with very long time frames for each
> > release.
> 
> Well, that's questionable, as after all a single version isn't alive for a
> year, there's security updates every 6 weeks. And regression finding on
> release is always pretty wonky. 

I think if you follow Thunderbird crash histories you wouldn't be saying this. We have many crashes which never appeared in non-release builds. (or in trace amounts)

> But I won't question your practices, after
> all IMHO nothing is as old as the software from yesterday. What I care about
> is that any changes to comfort you are not making things more complicated,

Note I am looking for effectiveness. If there are other ways to achieve my objectives I am happy to learn them. 

Isn't your bar of "not making things more complicated", if meant in absolute terms, a wee bit high of a bar?  


> unstable or expensive for uses of anything with "Firefox" in its brand name.

i wouldn't ask this of mozilla.  Let's discuss solutions please.

Comment 3

[Robert Kaiser]

(In reply to Wayne Mery (:wsmwk) from comment #2)
> Isn't your bar of "not making things more complicated", if meant in absolute
> terms, a wee bit high of a bar?  

Oh, I didn't mean it in absolute terms, I meant it relative to Firefox* stuff , just like the rest of the sentence. :)

Comment 4

[Lonnen :lonnen]

we will not set custom retention periods

Comment 5

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:beedell.roke_julian_lockhart]]

Currently, Soccorro retains traces for P6M. I imagine that it must continue to do so, by default, for the sake of storage. However, would the option to retain specific traces be feasible, if the user checks a box?

I ask because, for crashes like what bugzilla.redhat.com/show_bug.cgi?id=2386127 describes, the existence of a trace is the difference between it being diagnosable or not.

Apologies if not, but I thought that this was better than filing a new issue about it!

Comment 6

[Lonnen :lonnen]

Please open a new bug describing the desired behavior.

I am no longer the right person to make such a decisions. The triage owner, :sven, will be better equipped to answer