Closed Bug 520150 Opened 16 years ago Closed 16 years ago

crash data for 20090917 and later missing branch 1.9.3

Categories

(Socorro :: General, task)

Product:
Socorro
Component:
General
Platform:
x86
All
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bc, Unassigned)

Details

+++ This bug was initially created as a clone of Bug #517476 +++ The crash data dumps from 20090917 and later are missing the 1.9.3 branch. This appear to be fall out from crash-stats maintenance
The database's 'branches' table has no information with associations between product/versions and branches where the branch is equal to 1.9.3. Give us those associations so that they may be added to the system. However, the query in the daily URL should still actually contain the information that you seek. It's just not labeled with "1.9.3". You should find the 'branch' column to be NULL (/N) for those entries.
Up until 9/17, the reports did contain branch 1.9.3 for Minefield (Firefox 3.7*). I'm not familiar with the table. How does the table work? The branch value isn't contained in the database but is calculated from an association? Is the table used to map Firefox version into branch ? Can it operate on a pattern? I appears the problem isn't just that branch 1.9.3 information is lacking, it appears the table used for the matching is incorrect. Firefox 3.7a1pre is being reported as branch 1.9.2 instead of 1.9.3 Firefox 3.6b1pre is being reported with a null branch \N instead of 1.9.2 Firefox 3.0, 3.0.2, 3.0.3, and a number of others also report a null branch.
The 'branch' table is actually a view into another table called 'productdims'. The 'productdims' table is list of every product and version along with the associated branch and an enum with possible values of: 'major', 'milestone', or 'development'. The table is keyed by product/version or its sequence number. It serves as the primary link in the materialized views for identifying product/version. With its role as a dimensions table, it is the target for many foreign key relationships, therefore it must contain literal enumerations of the all the combinations product/version pairs and cannot operate on a pattern. Looking into this table, I see the apparent erroneous association between FF/7a1pre with 1.9.2. The other versions that you mention are, interestingly, missing entirely from the 'productdims' table. I'm currently running a query that will find all the product/version pairs for which we're receiving reports but have no 'productdims' entry. I will post again later asking for the associations that I cannot fill in myself. Then I will make an IT request to have these values pushed into the production database.
Information: There IS no branches table: That information is now in the productdims table. The association with product version is currently done 'by hand' See: http://code.google.com/p/socorro/wiki/TrackNewProductVersion and http://code.google.com/p/socorro/wiki/SocorroDatabaseSchema#productdims To allow for graceful transition, there is a branches view into the productdims table, so SELECT from branches still works, but INSERT doesn't There is a bug in place to make maintenance of the productdims table available via an admin interface: Bug #505261 and another bug I'm not finding
In the last month, we have received crashes for all of these product/version pairs. There are no entries in the 'productdims' table for them. I've filled in the branch and release for the ones that I can surmise. Could you please tell me the branch for the last one? product | version | branch | release ----------------------------------------------- Firefox | 3.0 | 1.9.1 | major Firefox | 3.0.1 | 1.9.1 | major Firefox | 3.0.2 | 1.9.1 | major Firefox | 3.0.2pre | 1.9.1 | development Firefox | 3.0.3 | 1.9.1 | major Firefox | 3.0a5 | 1.9.1 | milestone Firefox | 3.0a5pre | 1.9.1 | development Firefox | 3.0a6 | 1.9.1 | milestone Firefox | 3.0a6pre | 1.9.1 | development Firefox | 3.0a7 | 1.9.1 | milestone Firefox | 3.0a7pre | 1.9.1 | development Firefox | 3.0a8 | 1.9.1 | milestone Firefox | 3.0a8pre | 1.9.1 | development Firefox | 3.0a9pre | 1.9.1 | development Firefox | 3.0b1 | 1.9.1 | milestone Firefox | 3.0b2 | 1.9.1 | milestone Firefox | 3.0b2pre | 1.9.1 | development Firefox | 3.0b3 | 1.9.1 | milestone Firefox | 3.0b3pre | 1.9.1 | development Firefox | 3.0b4 | 1.9.1 | milestone Firefox | 3.0b5 | 1.9.1 | milestone Firefox | 3.0b5pre | 1.9.1 | development Firefox | 3.0pre | 1.9.1 | development Firefox | 3.1a1 | 1.9.1 | milestone Firefox | 3.1a1pre | 1.9.1 | development Firefox | 3.1b4pre | 1.9.1 | development Firefox | 3.6b1pre | 1.9.2 | development Firefox | 4.0a1pre | | development
Firefox 4.0a1pre is a temporary bogus version from 2008 that was originally reported as 2.0a1pre, but I don't think we want to use that. I would just leave that one null. The branches above are not correct. All Firefox 3.0.x should be 1.9 All Firefox 3.5.x should be 1.9.1 All Firefox 3.6.x should be 1.9.2 All Firefox 3.7.x should be 1.9.3
the database has some FF versions like 3.1x and 3.2x, what branch should be associated with them?
an IT request has been submitted to make this change to the database.
using 1.9 verses 1.9.0 for FF 3.0.X is in direct conflict with what I've been directed to do in Bug 519521 Comment #4. Who is the authority and how do I resolve this conflict?
(In reply to comment #6) > All Firefox 3.0.x should be 1.9 Bob and I talked and this should be 1.9.0. He agrees and shall say so here. :)
I used 1.9 since that was the existing output in prior logs for Firefox 3.0.x and I wasn't trying to change that since I didn't understand the reasons for making that choice previously. But if I do have a choice I would prefer 1.9.0 for Firefox 3.0.x since it is what I use when describing the branch and also is not a prefix of the other branches, 1.9.1, 1.9.2, 1.9.3, etc. Was there a reason previously to use 1.9 for the 1.9.0 branch? If not, lets make the break and use 1.9.0 in the crash dumps going forward.
Assignee: server-ops → nobody
Group: mozilla-corporation-confidential
Component: Server Operations → Socorro
Product: mozilla.org → Webtools
QA Contact: mrz → socorro
Data from 20091008-crashdata.csv.gz. Looks fixed to me but leaving open in case there is something else to do. product version branch Firefox 3.0.10 1.9.0 Firefox 3.0.11 1.9.0 Firefox 3.0.1 1.9.0 Firefox 3.0.11pre 1.9.0 Firefox 3.0.12 1.9.0 Firefox 3.0.13 1.9.0 Firefox 3.0.14 1.9.0 Firefox 3.0.15pre 1.9.0 Firefox 3.0.16pre \N Firefox 3.0 1.9.0 Firefox 3.0.2 1.9.0 Firefox 3.0.3 1.9.0 Firefox 3.0.4 1.9.0 Firefox 3.0.5 1.9.0 Firefox 3.0.6 1.9.0 Firefox 3.0.7 1.9.0 Firefox 3.0.8 1.9.0 Firefox 3.0.8pre 1.9.0 Firefox 3.0.9 1.9.0 Firefox 3.0a6 1.9.0 Firefox 3.0a6pre 1.9.0 Firefox 3.0a7 1.9.0 Firefox 3.0a7pre 1.9.0 Firefox 3.0a8 1.9.0 Firefox 3.0a8pre 1.9.0 Firefox 3.0a9pre 1.9.0 Firefox 3.0b1 1.9.0 Firefox 3.0b2 1.9.0 Firefox 3.0b2pre 1.9.0 Firefox 3.0b3 1.9.0 Firefox 3.0b3pre 1.9.0 Firefox 3.0b4 1.9.0 Firefox 3.0b5 1.9.0 Firefox 3.0b5pre 1.9.0 Firefox 3.0pre 1.9.0 Firefox 3.1a1 1.9.1 Firefox 3.1a1pre 1.9.1 Firefox 3.1b1 1.9.1 Firefox 3.1b1pre 1.9.1 Firefox 3.1b2 1.9.1 Firefox 3.1b2pre 1.9.1 Firefox 3.1b3 1.9.1 Firefox 3.5.1 1.9.1 Firefox 3.5 1.9.1 Firefox 3.5.2 1.9.1 Firefox 3.5.2pre 1.9.1 Firefox 3.5.3 1.9.1 Firefox 3.5.4 \N Firefox 3.5.4pre 1.9.1 Firefox 3.5b4 1.9.1 Firefox 3.5b5pre 1.9.1 Firefox 3.5b99 1.9.1 Firefox 3.6a1 1.9.2 Firefox 3.6a1pre 1.9.2 Firefox 3.6a2pre 1.9.2 Firefox 3.6b1pre 1.9.2 Firefox 3.7a1pre 1.9.3 Firefox 4.0a1pre \N
oops, I missed that the following are missing branches. Firefox 3.0.16pre \N Firefox 3.5.4 \N What can we do to tie the updating of the table in Socorro to the updating of the branches in the tree?
(In reply to comment #14) > oops, I missed that the following are missing branches. > > Firefox 3.0.16pre \N > Firefox 3.5.4 \N > > What can we do to tie the updating of the table in Socorro to the updating of > the branches in the tree? Is there any drawback to having unreleased versions in the db before the releases actually happen, i.e. is there any issue with IT doing the version bump in the db as soon as we get the 'go' from release-drivers to start a new release? releng doesn't check-in the version bumps until after the initial tagging step of a release. We don't have access to the socorro db AFAIK, but we could add "prodding IT to update the db" to our list of early-in-the-release activities, or IT could just key off the announcement in release-drivers.
I think that would be great. It would help alleviate the situation we have now where new versions end up with null branch every release cycle. For example, we already have the situation for 20091013 of product version build branch Firefox 3.0.15 2009100612 \N Firefox 3.0.16pre 2009100806 \N Firefox 3.0.16pre 2009101205 \N Firefox 3.0.16pre 2009101305 \N Firefox 3.5.4 20091006224018 \N Firefox 3.5.4 20091006225203 \N Firefox 3.5.4 20091007001339 \N Firefox 3.5.5pre 20091008031021 \N Firefox 3.5.5pre 20091011043555 \N Firefox 3.5.5pre 20091012031237 \N Firefox 3.5.5pre 20091012045012 \N Firefox 3.5.5pre 20091013030719 \N
coop, have you got a process in place for handling this going forward? lars, can we get the following updated which will bring us current with the ongoing builds? Version Branch 3.0.15 1.9.0 3.0.16pre 1.9.0 3.0b4pre 1.9.0 3.5.4 1.9.1 3.5.5pre 1.9.1 3.6b1 1.9.2 3.6b2pre 1.9.2 After that, lets close this bug out as fixed.
IT Bug 524558 submitted to have these added
(In reply to comment #17) > coop, have you got a process in place for handling this going forward? No, in the respin drama for 3.5.4 I forgot to ping IT to do the updates. I can use the SQL in https://bugzilla.mozilla.org/show_bug.cgi?id=524558#c0 as a template, update our releng release process docs, and educate the rest of the releng team for the next set of releases. Resolving since there's a separate bug (bug 524558) for adding the missing releases now.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
thank you everybody!
Component: Socorro → General
Product: Webtools → Socorro
You need to log in before you can comment on or make changes to this bug.