Closed Bug 649419 Opened 13 years ago Closed 13 years ago

Put channel into crash info sent to the server

Categories

(Toolkit :: Crash Reporting, defect)

Product:
Toolkit
Component:
Crash Reporting
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 526623

People

(Reporter: kairo, Unassigned)

Details

For keeping apart beta and release channels correctly with the new development process (they have the same version number scheme), we will need the channel in the crash reports.
Blocks: 649432
Rob, Mossop:
ted says one of you could do this part of getting the channel be sent in the crash reports, who can take this on?

We'd like to get this ASAP to be able to build Socorro UI based on that info.
I can likely add it in the next day or two
Heads up for LegNeato that this is wanted on Aurora to support the new versioning scheme for Beta and Release.
Ted, I was wondering if it would make sense to compile this somewhere for / in crashreporter since it is set at compile time? That way the client doesn't have to do anything (e.g. no client overhead).
We don't really have any place to hard-code annotations at compile-time, but you could stick it near startup if you wanted:
http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2998
I am not convinced we need this at all, though I may have missed something.

Only one version will be on beta or release at a time. When 5.0 moves to release beta users will be updated to 6.0. Are you worried about users who don't take that 6.0 beta update getting their crashes clumped in with the release? Can't socorro just keep a pointer to the version and build id of the last release and assume anything with the same version and lower build id is on beta? It wouldn't even be that much work as it only changes once every 6 weeks (and can in fact be automated fairly easily by pulling from releases/latest-firefox (or latest-mozilla-release) and reading the .txt file with the build id and changeset)
KaiRo, I'm going to wait on you getting buy in from LegNeato before looking at this further.
I'm not sure we need this either.  *All* of the reporting tools (socorro, input,...)  need a fair amount of work to extract data by build_id or collection of build_ids.  This will help us with better analysis of whats happening on mozilla-central in early stage development, and will help us analyzing individual RCs in the end game of releases.

Having the channel, might be a nice to have, but if we get the  release+build_id or we get release+build_id,build_id,...  that will solve this bug since release + build_ids since it can act as a proxy for channel as legneato points out.
(In reply to comment #8)
> I'm not sure we need this either.  *All* of the reporting tools (socorro,
> input,...)  need a fair amount of work to extract data by build_id or
> collection of build_ids.

Right. I just thought it's way easier to just have the channel available and be able to filter by that and not need to scrape a list of build IDs (or range of buil IDs + versions) that correspond to a certain channel, as we will probably want to have reports per channel and so we'll need to go through the hassle of deriving that somehow, as error-prone as that can be, while directly having the channel available would make all that a lot easier and probably is quite easy to do.
yeah, ease of use will be a problem, but if we get release+build_id,build_id,...  features we can layer a "channel" or other interesting combinations of builds using the admin panels of the reporting systems.
If you think it's reasonable to put up another layer of pulling things together for this, then we can surely go that way. I thought reporting the build ID with the other data would be a tiny change and increase easiness of aggregation of data - even if we might not have it in 5 yet.
Of course, not having the channel in the crash data means that any custom report or so that runs off CSVs will need to build up its own layer of correlating version+buildID combinations to channels.
(And, that said, I'd really like to have us be able to ignore versions in favor of channels for a lot of things.)
yeah, I wouldn't close this bug.  I just think its more important to do the buildid stuff first, since we really need more precision in nightlies and the end game.  Once that is done we can have a look and see if this is still needed.
Laura on the Socorro side says she would love to see this happening, as they could filter by channel for what to throttle and what to not throttle (as beta should not be throttled, only release should be).
Drivers, if you want this for Firefox 5 it should be fairly simple. I'm ok either way and just want to prioritize this against other work I am doing.
tracking-firefox5: --- → ?
We're tracking this, but don't treat this as a directive to work on this patch just yet.
tracking-firefox5: ? → +
Looks like we already send an annotation to differentiate release builds:
http://hg.mozilla.org/mozilla-central/annotate/2f41abc5a89d/toolkit/xre/nsAppRunner.cpp#l3555

That should be usable to differentiate beta from release. I think that makes this WORKSFORME?
(In reply to comment #16)
> Looks like we already send an annotation to differentiate release builds:
> http://hg.mozilla.org/mozilla-central/annotate/2f41abc5a89d/toolkit/xre/nsAppRunner.cpp#l3555
> 
> That should be usable to differentiate beta from release. I think that makes
> this WORKSFORME?

(In reply to comment #17)
> (see bug 526623)

Wow, thanks for digging this out, looks like many people have forgotten about that even though bug 526623 had intended for Socorro to use it!

I'm currently trying to verify, but I guess this bug ends up being a dupe of already fixed bug 526623 in the end.
No longer blocks: 649432
OK, confirmed over in bug 649432 that the data comes to Socorro, so bug 526623
was successful back then, we just didn't follow up on the Socorro side, and
this is a dupe.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
tracking-firefox5: + → ---
You need to log in before you can comment on or make changes to this bug.