Closed Bug 759911 Opened 8 years ago Closed 7 years ago

include human readable build ID, version, and channel in device info

Categories

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

x86
Gonk (Firefox OS)
defect

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+, firefox18 fixed, firefox19 fixed)

RESOLVED FIXED
B2G C1 (to 19nov)
blocking-kilimanjaro +
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed

People

(Reporter: lsblakk, Assigned: vingtetun)

References

Details

(Keywords: feature, Whiteboard: [LOE:M] [WebAPI:P0])

Attachments

(2 files)

We'll need this for  user-testing/qa/release channel info.
blocking-basecamp: --- → +
There's already an about:buildconfig. Is that enough?

If not, can you list the individual about: pages or individual pieces of information that are needed to be exposed?
Depends on: 759910
Summary: provide about: pages for b2g builds → include human readable build ID in an about: page
Summary: include human readable build ID in an about: page → include human readable build ID and channel in an about: page
I think we need to find an assignee for this bug. Given how close we are to shipping, we need this for basic testing.
blocking-kilimanjaro: --- → +
Dietrich, at minimum, going to about:  should show the human readable buildID and say something like "You are on the _______ channel".  We don't have the build IDs yet nor have we locked down a channel naming scheme but getting this as proof of concept so we can start testing updates along specific channels (dev->dev/production->production) would be great.  Do you have a person in mind to assign this to?
Where should this about page be?  Settings has an about phone page.
There's also the option of exposing it via about:buildconfig in the browser.

Cc'ing Mwu for information on the id itself.
(In reply to Dietrich Ayala (:dietrich) from comment #5)
> Cc'ing Mwu for information on the id itself.

Not sure what's being asked for so I probably don't have an answer.
For reference, here's our proposal for the versioning scheme itself, which has not been signed-off on or impelemented (but we hope to gain clarity on soon).

"We propose that we use the build tag as the version string for B2G releases. Our recommendation is for the build tag to look like (without brackets):

B2G{Major Version:1,2}/{Channel:Local,Dev,Nightly,Stable,Release,TEF,Carrier}/{Date/Time:YYYYMMDDHH}

An example Telefonica-specific build would look like:

B2G1/TEF/2012071423"
The goal is to have no carrier or OEM specific Gecko builds. All builds use the same bits.
(In reply to Andreas Gal :gal from comment #8)
> The goal is to have no carrier or OEM specific Gecko builds. All builds use
> the same bits.

This proposed version scheme is for all system bits, and not just Gecko. It would be bumped when any change (Gecko/Gaia/Gonk) is taken on a device hooked up to a specific update channel.

Having a single version for all system bits will make for significantly saner QAing and issue reproduction on B2G. Not having a unique version for all underlying system bits is fairly unheard of in the OS world, given the complexity of testing.
And when I say QA, I of course also mean post-release support of course.
Priority: -- → P2
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
Restoring the priority and basecamp blocking of this bug, same as in bug 759910 comment 7.  We have to have a comprehensible way to allow our test audience (pre-v1 release) to be able to talk with devs/QA/Sumo and file bugs on the build of the product they are testing.
blocking-basecamp: --- → +
Priority: P2 → P1
Additionally, for this bug we need to know what release channel a device is on which is also a pre-v1 shipping requirement.
Vivien, we thought you'd either be a good owner for this or be able to find someone who is more appropriate.  Thanks.
Assignee: nobody → 21
Whiteboard: [LOE:M] → [LOE:M] [WebAPI:P0]
Summary: include human readable build ID and channel in an about: page → include human readable build ID, version, and channel in device info
Adjusting this bug, we now know more about where people would look for this info and it seems that device info is where someone would intuitively search for their build identifying information.  If the "Device Info" button in settings shows this human-readable information that will meet the criteria we're trying to get here.
Comment on attachment 673187 [details] [diff] [review]
Gaia /Settings/ patch

lgtm
Attachment #673187 - Flags: review?(lsblakk) → review+
Comment on attachment 673186 [details] [diff] [review]
b2g/ patch

I'm not too familiar with the b2g code, but this looks right -- assuming it's been tested on local builds and i'm really just rubber stamping.
Attachment #673186 - Flags: review?(lsblakk) → review+
(In reply to Lukas Blakk [:lsblakk] from comment #19)
> Comment on attachment 673186 [details] [diff] [review]
> b2g/ patch
> 
> I'm not too familiar with the b2g code, but this looks right -- assuming
> it's been tested on local builds and i'm really just rubber stamping.

It has been tested locally and this is rubber stamp (like all the information of the device section for me).
Gaia: 57d0616
Whiteboard: [LOE:M] [WebAPI:P0] → [LOE:M] [WebAPI:P0] checking-needed-aurora
https://hg.mozilla.org/mozilla-central/rev/c2d82d7c1dbc
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Whiteboard: [LOE:M] [WebAPI:P0] checking-needed-aurora → [LOE:M] [WebAPI:P0]
https://hg.mozilla.org/releases/mozilla-aurora/rev/29d25d5ab558

(You don't need to request Aurora checkin, BTW. I have bug queries for that)
Both Dietrich and I have not been able to verify this on Nightly/Stable. Reopening.
Status: RESOLVED → REOPENED
Keywords: feature
Resolution: FIXED → ---
Target Milestone: --- → B2G C1 (to 19nov)
Duplicate of this bug: 759910
David let us know that some info not being displayed in the Setting is a known bug, not affecting all users, and being actively worked on.
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.