Last Comment Bug 790351 - B2G builds & crash reporting, step 3: set "correct" channel
: B2G builds & crash reporting, step 3: set "correct" channel
Status: RESOLVED FIXED
[LOE:S]
:
Product: Firefox OS
Classification: Client Software
Component: GonkIntegration (show other bugs)
: unspecified
: x86_64 Linux
: P1 normal (vote)
: B2G C2 (20nov-10dec)
Assigned To: Hubert Figuiere [:hub]
:
Mentors:
Depends on: 778341 789108
Blocks: b2g-crash-reporting 829593
  Show dependency treegraph
 
Reported: 2012-09-11 11:42 PDT by Robert Kaiser
Modified: 2013-03-04 08:49 PST (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
-
+
fixed


Attachments

Description Robert Kaiser 2012-09-11 11:42:36 PDT
From bug 789108 comment #3:
3) Set the release ("update") channel to one of the usual ones fitting the version number set for the product - most probably this would be "nightly". Note that this has obvious connections to the update system and we need to be careful to not trigger unexpected stuff there.

With that step, our crash stats system would be able to generate useful topcrash reports, etc. (due to how other products work, esp. Firefox desktop, this is wired to having the "correct" channel set).


This is also connected to bug 778341 (and bug 785698).
Comment 1 Marshall Culpepper [:marshall_law] 2012-09-28 19:50:25 PDT
I believe this should be covered by Bug 795479, re-open if I'm mistaken.

*** This bug has been marked as a duplicate of bug 795479 ***
Comment 2 Robert Kaiser 2012-09-29 11:47:19 PDT
No, this is no dupe, this bug is about setting the "nightly" channel in the builds. Right now it's set to "default", which is the default.
Comment 3 Lawrence Mandel [:lmandel] (use needinfo) 2012-10-29 11:55:37 PDT
kairo - Is the use of one of the desktop channel names required for Socorro? If not, B2G is on a different type of release cadence. Perhaps "default" is a suitable value for B2G at this time.
Comment 4 Robert Kaiser 2012-10-29 12:24:23 PDT
Socorro requires the use of the same channels and way of putting build information on ftp.m.o to function properly. And unfortunately, it isn't really able to be flexible on that, as it would require quite some work to change those assumptions.
Right now where e.g. the otoro builds send a version of "18.0a2" (I don't have access to an unagi) we already fail to display information correctly on crash-stats.
Comment 5 Lawrence Mandel [:lmandel] (use needinfo) 2012-10-29 13:13:28 PDT
From c4 it sounds like the reported name and version need to match the current train. Is that correct? Can you please list the specific name and version requirements for Socorro?
Comment 6 Robert Kaiser 2012-10-29 13:32:05 PDT
(In reply to Lawrence Mandel [:lmandel] from comment #5)
> From c4 it sounds like the reported name and version need to match the
> current train. Is that correct? Can you please list the specific name and
> version requirements for Socorro?

Yes, current Socorro is built with heavily having the assumptions of our channel system at its base. "*a1" versions require to be on the "nightly" channel, "*a2" on "aurora", classic betas require the final release number, "beta" channel and build info for every beta in an appropriate -candidates directory on FTP, and releases can be on "release-*" or "default" channels - for any versions to be added to Socorro, we scrape nightly/ and -candidates/ directories on FTP as appropriate and add that info. Support for "rapid" (daily) betas should exist but hasn't been tested in production yet.
Comment 7 Lawrence Mandel [:lmandel] (use needinfo) 2012-10-29 13:41:10 PDT
B2G will ship with an older version of Gecko than may be in the current set of trains. Do you expect a problem with Socorro handling data submitted with an older Gecko version? How does Socorro handle older releases?
Comment 8 Robert Kaiser 2012-10-29 13:58:42 PDT
(In reply to Lawrence Mandel [:lmandel] from comment #7)
> B2G will ship with an older version of Gecko than may be in the current set
> of trains. Do you expect a problem with Socorro handling data submitted with
> an older Gecko version? How does Socorro handle older releases?

B2G mostly doesn't care how old a release is (we might want to tweak the "lifetime" of single versions somewhat for B2G, but that should be dable pretty easily), and anyhow only cares about the "current set of trains" with respect to every signle product, so if there's different versions that are current for B2G than for some other product, that's no problem - as long as the scheme of version numbers and channels fits and we have FTP information.
ESR, SeaMonkey, and even Camino (to some extent) work fine with their different requirements.


(As a side note, when I say how easy or hard something is to change in Socorro, I'm making assuptions based on my knowledge - after all, I'm "just" a stability program manager that closely works with the Socorro team. I know pretty well what the current design can do as I was involved in all specs they implemented in the last 18 months or so, but if we come to assessments of changes that need to be done, we'd need to pull in :laura as the manager of the Socorro/webtools team. As I know they are pretty maxed out on workforce for at least this qurter and probably more, I'm just trying to find a way to make us work with what's there. If you want to talk those things over more in detail, let's move that to IRC or Vidyo and only report the actions/results coming out of that here so we don't overwhelm Bugzilla followers with tangents.)
Comment 9 Lawrence Mandel [:lmandel] (use needinfo) 2012-10-29 14:20:25 PDT
Marshall - Do you have enough information to update the build channel so that Socorro reporting will work?
Comment 10 Marshall Culpepper [:marshall_law] 2012-10-30 10:41:15 PDT
So after chatting some in IRC w/ rhelmer, lsblakk and jgriffin, it looks like we'll need to rename our current "stable" (dogfooding) channel to "beta" when that happens for Firefox in 2 weeks.

For our stable release, we might have non-socorro update channel names, but it isn't clear to me right now. We are still ironing out details WRT updates after v1..
Comment 11 Alex Keybl [:akeybl] 2012-11-21 06:11:55 PST
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Comment 12 Dietrich Ayala (:dietrich) 2012-11-28 11:40:09 PST
No update for almost a month. Marshall, what's the status of this? How can we move this forward?
Comment 13 Faramarz [:faramarz] 2012-12-03 22:56:27 PST
:marshall_law let me know if you need to get some help here.  especially since this was estimated as a 'small'.  there are some bugs depending on this being resolved...
Comment 14 Marshall Culpepper [:marshall_law] 2012-12-05 11:04:07 PST
Hey guys. The main thing holding this back has been the rename to "beta" for dogfood updates, which is happening this week.

Marking as resolved.
Comment 15 Robert Kaiser 2013-01-10 10:09:18 PST
(In reply to Marshall Culpepper [:marshall_law] from comment #14)
> Hey guys. The main thing holding this back has been the rename to "beta" for
> dogfood updates, which is happening this week.

I don't see any crash reports being sent with a "beta" channel set, so I'm reopening this.
Comment 16 Jason Smith [:jsmith] 2013-01-10 17:27:30 PST
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #15)
> (In reply to Marshall Culpepper [:marshall_law] from comment #14)
> > Hey guys. The main thing holding this back has been the rename to "beta" for
> > dogfood updates, which is happening this week.
> 
> I don't see any crash reports being sent with a "beta" channel set, so I'm
> reopening this.

Please file a separate bug on this and nom it. Re-closing.
Comment 17 Robert Kaiser 2013-01-10 17:45:03 PST
(In reply to Jason Smith [:jsmith] from comment #16)
> Please file a separate bug on this and nom it. Re-closing.

I respectfully disagree. This has never been fixed, so it doesn't deserve to have that status of resolved/fixed. Comment #14 assumed a fix that never happened. I'm fine with a re-nom, but the bug wasn't fixed so it's correct to reopen it.
Comment 18 Andrew Overholt [:overholt] 2013-01-11 00:55:37 PST
Is this fixed by bug 829121?
Comment 19 Andrew Overholt [:overholt] 2013-01-11 04:42:42 PST
I spoke with Hub and bug 829121 doesn't fix this.

Marshall isn't sure why the channel isn't making it through to crash reports since it's set.

We can't fix this for basecamp but let's keep this on the radar for v1.
Comment 20 Hubert Figuiere [:hub] 2013-01-11 05:42:43 PST
I flashed the latest beta build unagi_beta_20130109070203.zip on my phone. 
I caused a process to crash and examined the .extra file (I disabled the wifi to ensure that the report wasn't sent)

I have the following entry:

ReleaseChannel=beta

I think we are good. KaiRo, what's our next move?
Comment 21 Robert Kaiser 2013-01-11 06:36:42 PST
(In reply to Hub Figuiere [:hub] from comment #20)
> I think we are good. KaiRo, what's our next move?

Can you show me some crash reports that have this set?
Comment 22 Hubert Figuiere [:hub] 2013-01-11 07:00:23 PST
Try this one 

https://crash-stats.mozilla.com/report/index/18f6ed0f-5858-4116-b176-55ffa2130111

I just submitted it, but that the ABRT I mentionned above: I didn't have wifi setup.
Comment 23 Robert Kaiser 2013-01-11 07:17:11 PST
(In reply to Hub Figuiere [:hub] from comment #22)
> https://crash-stats.mozilla.com/report/index/18f6ed0f-5858-4116-b176-
> 55ffa2130111

OK, this looks good. So bug 829593 is the next step to get topcrash reports at least of those people on the beta channel.

Note You need to log in before you can comment on or make changes to this bug.