Jetpack crashes will be ProcessType=jetpack Content crashes will be ProcessType=content Jetpack crashes will also have a JetpackID and a JetpackName Todo list: - Add Hbase support (deinspanjer) - Add PG support (lars or ozten) - Changes to processor (lars) - Changes to UI (ozten/ryan/laura) - Icons for the UI (chowse) bsmedberg says these will start appearing in about two weeks but we can push this out in 1.8, no need for a special release. I'll file separate bugs shortly.

Can we attach a raw dump and meta file for the both a Jetpack and a Content crash?

I think the best thing to do for testing now is just take an existing plugin crash report, change the ProcessType=jetpack and ProcessType=content and use that for testing. The final metadata may change a little, but the basics won't. I won't have real product submissions until beta3 at this point, and even that might not have UI.

The meta data is the problem. If we don't know what it looks like, we can't make appropriate changes to the database to accommodate it. We're not sure if we need to make an additional table or if it can just be appended to a reports record. JetpackID and JetpackName - what are their types and associated data lengths? Is a JetpackID unique enough to identify a JetpackName? Or are they unique only when taken together? If there are other metadata fields coming too, it might have a major impact on how this gets implemented. I'm really uncomfortable making database schema changes that could suddenly be found sub-optimal or completely wrong. It's painful to change the database once it gets pushed to production.

ok, what I want for the short term is no additional metadata other than the existing processtype stuff. I don't think we'll know much about jetpackid/jetpackname until the jetpack guys actually start getting crashes and figure out how they want to correlate and present that data.

(In reply to comment #4) This sounds like we need to support search by process_type, but we will not support searching for specific Jetpacks by name. So process_type = 'jetpack' or 'content' in the reports tables and punt on features that would require the metadata.

FYI content process crash reporting has landed for Fennec, bug 581335. They're not currently setting ProcessType=content, I filed bug 614610 on that.

Jetpack crash reports are also going to start being submitted with beta8, at least in some cases.

Can we get some sample crashes, bsmedberg?

What do you mean by sample crashes? Local minidump files, or local JSON files that go with the miniidumps, or crash IDs that have already been submitted?

I think (minidump and json) or (ID for one that has been submitted) would be excellent.

Jetpack: http://crash-stats.mozilla.com/report/index/7d6c6805-cec9-4f71-ba93-f61d42101129 Content: https://crash-stats.mozilla.com/report/index/9d0fafb8-3611-4300-beb5-2ff672101129 Note that these don't have the ProcessType property in the JSON yet, that still needs to be implemented in bug 614610.

I tried to submit http://crash-stats.mozilla.com/report/pending/e0896b54-26b0-4553-b9c6-bed9c2101129 with a correct ProcessType, but it's not responding, so I suspect that socorro isn't accepting ProcessType=jetpack yet.

We need to get as much of this done for 2.1 as possible.

:bsmedberg: I took a look at your e0896b54-26b0-4553-b9c6-bed9c2101129 crash. It did process and correctly shows the process_type == jetpack. Looking at the raw dump received by the collector however, I don't see any additional meta data in the form of JetpackID and JetpackName. Is that a breakpad feature that doesn't exist yet?

here's my pending questions that I need with regards to jetpack crashes: Is a JetpackID unique enough to identify a JetpackName or are they unique only when taken together? Or is it unique only when the crash ooid/uuid is included? What are their types and associated data lengths?

I'm not sure what "unique enough to identify a jetpack name" means. Jetpack IDs are the unique identifiers for the extension. The name is just a human-readable extension name so that we don't have to use AMO or something to map IDs back to extensions. They are both strings of indeterminate length. But really, we disabled jetpack processes in Firefox 4 beta and haven't turned them back on, so content crashes are by far the higher priority.

you've actually answered the question. There is a 1:1 relationship between the id and the name. You could send just the id and we'd still have enough information to associate the crash with a specific jetpack. Because you're sending both, I was concerned that the relationship wasn't 1:1. We'll likely implement this with a new 'jetpack' table containing ids and names. The reports table will have only the id.

It is possible that multiple jetpacks will have the same name (but different IDs), so it's technically 1:many, and its reasonably likely that a jetpack name may change over time. But those are probably not important details...

Jetpack crashes are off the radar for now. Last remaining Content bugs are slated for 2.2 and later: pushing tracker out.

Dependent bugs are still open, moving

Last dependent bug is in a different milestone. Moving.

At long last...

Dependent bugs have been verified. Automation and manual bfts are passing.