Sometimes it's useful for the application to write custom data into crash reports. Ideally, one would want to add a new field, and have it show up in crash reports on crash-stats. The problem is that if I just add a new field, as far as I know, it won't be shown on crash-stats.
The way in which we work around that in the Gfx team is to use the AppNotes field, which is a free-form text field that is shown on crash-stats. This works nicely, but is limited to less than 1 kilobyte. So if another bit of code wrote a lot of stuff already, you can get truncated.
So I would like that:
* either it gets well-documented how to add new fields and how to control how they appear on crash-stats;
* or one just says that AppNotes is all we need, and then we probably need to remove the 1 kB constraint.
Examples of stuff we do with AppNotes: bug 627464
Example of how we analyse this data: bug 640286
(In reply to Benoit Jacob [:bjacob] from comment #0)
> * either it gets well-documented how to add new fields and how to control
> how they appear on crash-stats;
I think it's pretty well-documented how to add annotations to a crash report, if not, you#re right that it should be. To get those fields into Socorro, we need explicit bugs filed about adding each of them to either the DB, or the UI to view a crash report, or both. We cannot expose things in either automatically, as some field might be privacy-sensitive, and the DB needs to know about types of fields, etc. which we also probably cannot automate (also, the DBAs seem to like to normalize DB data, which always needs manual work).
> * or one just says that AppNotes is all we need, and then we probably need
> to remove the 1 kB constraint.
No, I'm pretty mad about our already existing over-use of app notes and would rather have that field removed completely than its use extended.
Our current plan is to allow for a JSON field that can be easily modified. This is dependent on upgrading to 9.2, which should happen relatively soon.
There's at least one blocker to easy schema changes, which is partitioning and the locks associated with production changes. But the JSON field would buy us quite a bit in terms of flexibility and future-proofing.
In any case, I support putting as much as is reasonable into a free-ish form JSON field inside of Postgres, and supporting lots of transform operations on it moving forward.