Closed
Bug 759910
Opened 12 years ago
Closed 12 years ago
provide human readable buildID for b2g builds
Categories
(Firefox OS Graveyard :: General, defect, P1)
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+)
People
(Reporter: lsblakk, Assigned: jhford)
References
Details
(Whiteboard: [WebAPI:P0])
We'll need this for user-testing/qa/release cycling.
Updated•12 years ago
|
blocking-basecamp: --- → +
Comment 1•12 years ago
|
||
Thanks for +ing for blocking-basecamp. Also setting this as a P1 since we need to be able to compare build versions asap. Finally, assigning to John since he's driving the build work. John - please provide an estimate when you can.
Assignee: nobody → jhford
Priority: -- → P1
Comment 2•12 years ago
|
||
John - can you provide status?
Assignee | ||
Comment 3•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #2) > John - can you provide status? Hi Alex, I've been focused on getting our desktop B2G builds going. I am working on a tool that will generate and insert a repo manifest that describes the state of the repositories used in a given build. Once I have that landed, I'll be able to figure out a way to generate a build id based on the manifest.
Updated•12 years ago
|
blocking-kilimanjaro: --- → +
Reporter | ||
Comment 4•12 years ago
|
||
FYI, I just did a build of gaia from the downloadable zip of the gaia github repo (not sure why I can't clone it), and the Git commit into once this is installed on the phone says: 2012-07-08 22:06:04 Unknown Git commit, build date shown here I know this to be https://github.com/mozilla-b2g/gaia/commit/5803383889d6af54e8aa1073656062a8c77f6294 from 2012-07-07 So, let me know if you need another bug on that or if your plan from comment 3 will eliminate the need for the Settings: About Phone section to have this info displayed properly where the build is reflective of what changeset and not of the time it got put on the phone.
Assignee | ||
Comment 5•12 years ago
|
||
The complication here is that there is currently more than one commit id that describes a given build of B2G. Having the Gaia version is helpful, but far from a complete picture. I am working on a better branching/tagging strategy which would allow us to have a single sha-1 ID of the b2g-manifest repository that would describe a full build of B2G on github, https://github.com/mozilla-b2g/B2G/issues/54 In the meantime, if you have a full build of B2G and need to find out which version of a given repository was used, you can grab that off the device/emulator with: adb pull /system/sources.xml sources.xml To replicate the environment used to build the software on your device/emulator , you can clone all the repositories with: git clone github.com:mozilla-b2g/B2G cd B2G ./config.sh <device> sources.xml
Updated•12 years ago
|
Priority: P1 → P2
Comment 6•12 years ago
|
||
Renom if you think we can't ship a v1 without this.
blocking-basecamp: + → ---
Reporter | ||
Comment 7•12 years ago
|
||
As far as I know, we are not shipping a v1 product without doing internal dogfooding and testing which means that this is still a P1 basecamp blocker as it's standing in the way of a concise and human-usable way of performing QA on our product. There's no way we can expect even QA, let alone other MoCo employees who will be testing our product to be able to use adb calls to get a sources.xml file in order to file bugs or talk with devs about issues they come up against. John, we talked last week about having the manifest for the sources and you mention doing a sha-1 ID of the manifest for a build - how much longer until we can start relying on being able to create that on a per-build basis so that it can be fed into the about: page asked for in bug 759911?
blocking-basecamp: --- → +
Priority: P2 → P1
Updated•12 years ago
|
Whiteboard: [WebAPI:P0]
Comment 8•12 years ago
|
||
John, any update here?
Assignee | ||
Comment 9•12 years ago
|
||
I've heard multiple requests for what this Build ID should be, how it should be generated and on what information it should be based. I also don't personally know how releng plans to actually generate the builds of all the parts of Firefox OS. I think we need to separate this bug into two concerns: 1) How are we going to generate a B2G build id? 2) How do we take a computed build id and make it available on the phone? For the first concern, we need to figure out how arbitrary or not the build id should be and what it represents. We need to figure out how these build ids should change (or not) when we have updates that don't change the entire system image. My thought is that we should have build ids for each component that gets updated as a single unit (i.e. one per gecko, gaia and gonk) and display those independently. We already have a Gaia identifier shown and Gecko contains its own buildid. I'll work on adding a timestamp based buildid to gonk. It's fairly arbitrary, but sources.xml is the correct way to figure out what was built.
Comment 10•12 years ago
|
||
I think we can combine Gecko/Gaia, since they're being packaged together currently. In a perfect world, we'd look something like: ==Pre-Release== Channel: Stable B2G: v1.2 (YYYYMMDDHHMM) Gonk: Firmware: ==Post-Release== Channel: Release B2G: v1.2 Gonk: Firmware: Where the B2G major/minor version is specified in some file (as we do in Firefox), and the BuildID (YYYYMMDDHHMM) is stamped on at build time. I don't have strong feelings on what we do about Gonk/Firmware versioning - we can leave this as changesets for now until we figure something out.
Comment 11•12 years ago
|
||
Hi All, I've been assigned to a similar issue, currently the os version (or B2G version) is set in b2g/confvar.sh, and the b2g/chrome/content/settings.js is doing a hack of writing these information into IndexedDB at launch time. Please reference bug 790158 for more details, thanks.
Comment 12•12 years ago
|
||
In the meantime, one way to get build id, with the phone connected via usb, is: $ adb shell cat /system/sources.xml
Comment 13•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #10) > I think we can combine Gecko/Gaia, since they're being packaged together > currently. In a perfect world, we'd look something like: This is not yet true, the best would be to have one as a submodule of the other or merging the sources. > Where the B2G major/minor version is specified in some file (as we do in > Firefox), and the BuildID (YYYYMMDDHHMM) is stamped on at build time. I > don't have strong feelings on what we do about Gonk/Firmware versioning - we > can leave this as changesets for now until we figure something out. I recommend to replace the build time by a committer timestamp, which is way more valuable in a linear history and which will not change across compilations. A committer timestamp can be obtained with « git show -s --format="%ci" » and is a good approximation of a sha1 in the history of a branch.
Comment 14•12 years ago
|
||
(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #13) > This is not yet true, the best would be to have one as a submodule of the > other or merging the sources. Aren't Gecko/Gaia packaged together in OTA updates? A developer should be able to trace a buildID back to the corresponding Gecko/Gaia changesets. I'd appreciate if you could clarify why you think that isn't doable. > I recommend to replace the build time by a committer timestamp, which is way > more valuable in a linear history and which will not change across > compilations. A committer timestamp can be obtained with « git show -s > --format="%ci" » and is a good approximation of a sha1 in the history of a > branch. The identifier needs to be easily entered on a computer when filing a bug. Date/Times make a lot of sense to people.
Comment 15•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #14) > (In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #13) > > This is not yet true, the best would be to have one as a submodule of the > > other or merging the sources. > > Aren't Gecko/Gaia packaged together in OTA updates? A developer should be > able to trace a buildID back to the corresponding Gecko/Gaia changesets. I'd > appreciate if you could clarify why you think that isn't doable. I don't know about OTA packages, and for sure you can number the released packages. What I mentioned is that this cannot be used to identify developer/home-made versions because Gaia and Gecko are living in different repository which are not yet correlated. > > I recommend to replace the build time by a committer timestamp, which is way > > more valuable in a linear history and which will not change across > > compilations. A committer timestamp can be obtained with « git show -s > > --format="%ci" » and is a good approximation of a sha1 in the history of a > > branch. > > The identifier needs to be easily entered on a computer when filing a bug. > Date/Times make a lot of sense to people. The committer timestamp, is a date & time which can almost represent a commit in a git repository without the verbosity and readability issues related to sha1.
Assignee | ||
Comment 16•12 years ago
|
||
The problem with that timestamp is that it's per repository. We have ~70 repositories that make up the gonk layer, one for gecko and one for gaia. We'd need to have so many timestamps, that it'd be easier to just grab the sources.xml file. The sources.xml is the absolute best source of truth regarding revisions. What is desired is something that uniquely identifies a specific build. One set of revisions could conceivably have more than one build, especially in a release process. Because of that, we need something that uniquely identifies the specific build of each shippable component. Gecko already has this, gaia doesn't actually compile code and gonk doesn't have anything. I've opened a pull request that generates a buildid for the gonk layer using an arbitrary identifier: https://github.com/mozilla-b2g/gonk-misc/pull/31 This is something that can uniquely identify a specific *build* of gonk.
Comment 17•12 years ago
|
||
Now that the dogfood phones are out, could this please be expedited? I'm sometimes having to type my full Git commit hash out while filing bug reports (technically I don't have to, but...), but it'll be nice to consolidate to some form of agreed format here.
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Target Milestone: --- → B2G C1 (to 19nov)
You need to log in
before you can comment on or make changes to this bug.
Description
•