MTBF missing Thunderbird 3.0b2 milestone, and development 3.0b3pre & 3.1a1pre // 3.0b2 topcrash no results

RESOLVED FIXED

Status

Socorro
General
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: wsmwk, Assigned: ozten)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

9 years ago
+++ This bug was initially created as a clone of Bug #472179 +++

after bug 479123 Add Thunderbird 3.0b2 to crash-stats.m.c

MTBF missing Thunderbird 3.0b2 milestone, and development 3.0b3pre & 3.1a1pre
http://crash-stats.mozilla.com/mtbf/of/Thunderbird/development

3.0b2 topcrash = 
no results
http://crash-stats.mozilla.com/topcrasher/byversion/Thunderbird/3.0b2
(Assignee)

Comment 1

9 years ago
What are the start and end dates for 
version, release, start_date, end_date
3.0b2, milestone, ?, ?
3.0b3pre, development, ?, ?
3.1a1pre, development, ?, ?

Adding dependency on 472157. We need to fix the cron so it can be run to populate just 3.0b2 in the past.
Depends on: 472157
(In reply to comment #1)
> What are the start and end dates for 
> version, release, start_date, end_date

end date doesn't seem to make much sense... is it the end of MTBF tracking or something?

what about start date? is that first release, first test build?

3.0b2, milestone, 20090226, unknown  <- release date
3.0b3pre, development, 20090219, unknown  <- day of first 3.0b3pre nightly
3.1a1pre, development, 20090126, unknown <- day of first regular 3.1a1pre nightly (although we didn't have mac builds until 20090227).
(In reply to comment #2)
> end date doesn't seem to make much sense... is it the end of MTBF tracking or
> something?

Yeah, there's no point in MTBF running for a version forever. For Firefox, we settled on 60 days because it's enough to see the trend a release is going (almost always up) and because we tend to release once every 30-45 days.

> what about start date? is that first release, first test build?

Depends on what you want. Again, for Firefox, we settled on the release date for major and milestone builds and the first nightly for development builds.
wayne: any opinion on start date, end date?

These are the dates:
https://wiki.mozilla.org/Thunderbird:Thunderbird_3.0b2
    * Slushy String freeze date: 2009-2-10 — (Feb 10, 2009)
    * Slushy Code Freeze date: 2009-2-12 — (Feb 12, 2009)
    * Firm String / Code freeze date: 2009-2-17 — (Feb 17, 2009)
    * l10n-mozilla-1.9.1 freeze date: 2009-2-19 — (Feb 19, 2009)
    * Target Build Ship date: 2009-2-24 — (Feb, 24 2009)
    * Actual Ship date:  2009-2-26 — (Feb, 26 2009)
(Reporter)

Comment 5

9 years ago
(In reply to comment #4)
> wayne: any opinion on start date, end date?
mark's got it covered in comment 2. thanks
So, based on previous comments, I think we want:

version, release, start_date, end_date
3.0b2, milestone, 20090226, 20090427
3.0b3pre, development, 20090219, 20091231
3.1a1pre, development, 20090126, 20101231

For 3.0b2 this is approx 60 days.
For the pre versions, end of this year for 3.0x builds, end of next year for 3.1x builds, I've based this on the fact that we want to track development changes continuously and we have no ideas of when the next version bump will be. When we get to that point, I'm assuming we can re-adjust the date accordingly.
Ping: I believe all the data is here now. Can we get this added please?
Austin: Can you hook Thunderbird up here?
Assignee: nobody → mozilla.bugs.aking
(Assignee)

Updated

9 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

9 years ago
Filed IT Ticket 486706
Depends on: 486706
(Assignee)

Comment 10

9 years ago
Except for back-filling dates in the past (472157), this should be good to go.
(In reply to comment #10)
> Except for back-filling dates in the past (472157), this should be good to go.

I believe this is fixed now (the site certainly looks ok), marking fixed. bug 472157 can handle back-filling of dates.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.