Closed Bug 790351 Opened 12 years ago Closed 11 years ago

B2G builds & crash reporting, step 3: set "correct" channel

Categories

(Firefox OS Graveyard :: GonkIntegration, defect, P1)

x86_64
Linux
defect

Tracking

(blocking-basecamp:-, b2g18+ fixed)

RESOLVED FIXED
B2G C2 (20nov-10dec)
blocking-basecamp -
Tracking Status
b2g18 + fixed

People

(Reporter: kairo, Assigned: hub)

References

Details

(Whiteboard: [LOE:S])

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).
blocking-basecamp: --- → ?
Assignee: nobody → marshall
blocking-basecamp: ? → +
Whiteboard: [LOE:S]
I believe this should be covered by Bug 795479, re-open if I'm mistaken.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Priority: -- → P1
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.
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.
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?
(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.
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?
(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.)
Marshall - Do you have enough information to update the build channel so that Socorro reporting will work?
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..
Marking for C2, given this meets the criteria of known P1/P2 blocking-basecamp+ bugs at the end of C1.
Target Milestone: --- → B2G C2 (20nov-10dec)
No update for almost a month. Marshall, what's the status of this? How can we move this forward?
: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...
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.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → FIXED
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
blocking-basecamp: + → ?
Is this fixed by bug 829121?
Flags: needinfo?
Flags: needinfo?(marshall)
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.
Assignee: marshall → hub
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Flags: needinfo?(marshall)
Flags: needinfo?
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?
Flags: needinfo?(kairo)
(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?
Flags: needinfo?(kairo)
Blocks: 829593
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.
(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.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.